Implement auth by using secrets

[stefanandres]

Hi, currently it seems like you have to put plaintext secrets into the values.yaml to configure the auth secret.

valkey-helm/valkey/values.yaml

Line 151 in 1f71dbc

# user default on >defaultpassword ~* &* +@all

We should support being able to private an existing k8s secret to avoid having to put plaintext secrets into the value configuration.

[stefanandres]

Cool, #14 seems to work on exactly this.

[pree]

Until the PR is merged we are using the following configuration:

  auth:
    enabled: false # auth will be enabled using extraValkeySecrets
  valkeyConfig: |
    aclfile /secrets/users.acl
  extraValkeySecrets:
    - name: valkey-users
      mountPath: /secrets

and having the users.acl inside the secret

[bogatuadrian]

Maybe there are cases in which you don't want to do this, but isn't the SHA-256 password hash exactly for this use-case, when you don't want plaintext password in the config file?

From the ACL documentation:

#<hash>: Add this SHA-256 hash value to the list of valid passwords for the user. This hash value will be compared to the hash of a password entered for an ACL user. This allows users to store hashes in the acl.conf file rather than storing cleartext passwords. Only SHA-256 hash values are accepted as the password hash must be 64 characters and only contain lowercase hexadecimal characters.

Hope this helps someone.

[stefanandres]

In a lot of enterprise environments, passwords are stored in tools like vault and then stored in k8s secrets, so having the option to read the password (hashed or not) from secrets is a needed feature for those environments.