Can't connect to Valkey when using password from existing secret

[franz-dalitz]

Name and Version

bitnami/valkey 2.2.0

What architecture are you using?

None

What steps will reproduce the bug?

Environment: Rancher managed RKE2 clusters running on OpenSUSE Leap with applications managed by ArgoCD + Kustomize.

I created the secret "valkey" with the "password" field by just writing a secret manifest and applying it to the cluster in the same namespace as my valkey:

apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: valkey
data:
  password: my_password_in_base64

This is my kustomization:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
helmCharts:
- name: valkey
  repo: oci://registry-1.docker.io/bitnamicharts
  releaseName: valkey
  version: 2.2.0
  valuesFile: ../../../base/valkey/values.yaml
  namespace: dev

I then tried to connect to valkey-primary using a client container as described in one of the valkey guides: https://valkey.io/blog/using-bitnami-valkey-chart/

kubectl run --namespace dev valkey-client --restart='Never' --env VALKEY_PASSWORD=my_valkey_password  --image docker.io/bitnami/valkey:8.0.0-debian-12-r0 --command -- sleep infinity

kubectl exec --tty -i valkey-client --namespace dev -- bash

Then doing valkey-cli -h valkey-primary and auth my_password.

Are you using any custom parameters or values?

this is my values.yaml file content:

global:
  defaultStorageClass: local-path

auth:
  enabled: true
  usePassword: true
  existingSecret: valkey
  existingSecretPasswordKey: password

What is the expected behavior?

I'd assume a connection to be established successfully, then being able to test the setting and getting of values.

What do you see instead?

I get the following error: (error) WRONGPASS invalid username-password pair or user is disabled., even though I made sure of course, that namespaces and my chosen password are identical across all places.
Checking the valkey-primary-0 pod with printenv I can see that the VALKEY_PASSWORD env var is correct, yet connecting doesn't work.

Additional information

I had Valkey deployed with its own password generation before, which worked flawlessly, though either valkey rotates passwords sometimes or there is an issue on my end with Argo, but since the password kept changing other pods using Valkey would lose the initially correct password and the ability to connect to Valkey, so I assumed this is what I need to do.
I also tested the password file version as suggested on the artifacthub page: https://artifacthub.io/packages/helm/bitnami/valkey but that didn't work, exactly the same issue.

[carrodher]

Is this your first deployment? Please note that Helm does not automatically remove PVs/PVCs when uninstalling Helm charts. If you reinstall the chart using the same name and/or namespace, there may be a conflict between the password stored in the PV from the initial deployment and the new random password generated during subsequent installations.

To avoid this conflict, you can:

• Pass the original password as a parameter during the installation.
• Use a different name or namespace for the new deployment.
• Manually remove the PVs/PVCs from the previous deployment.

[franz-dalitz]

it's not my first deployment since i had it running before, when it was managing its password itself.
whenever i tried to reinstall though i cleared the pvcs in rancher and saw how their volumes were removed and then created again, so i'm sure each attempt started with a blank pv.

[carrodher]

Can you reproduce the issue by installing the Helm chart in a brand new namespace?

[franz-dalitz]

yes, bypassing argo, just going raw from the master node via kubectl kustomize with the same files after creating a new namespace, the same thing happens.

[github-actions]

This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.

[github-actions]

Due to the lack of activity in the last 5 days since it was marked as "stale", we proceed to close this Issue. Do not hesitate to reopen it later if necessary.

[franz-dalitz]

this still doesn't work for me. i updated my chart version to 2.2.1 and get the same error.

[franz-dalitz]

and the same happens when i use a password file instead.
am i missing some sort of setting?
is maybe simply somehow the default user disabled when using one of these two options?
using auth.password works just fine...

[franz-dalitz]

the global.auth.password variant documented on the artifacthub page also does not work for me, only exactly the auth.password option.

[juan131]

Hi @franz-dalitz

I was unable to reproduce the issue. These are the steps I followed:

• I created a secret my-valkey-secret with a password key

$ kubectl create secret generic my-valkey-secret --from-literal=password=some_password
$ kubectl get secret my-valkey-secret -o json | jq -r .data
{
  "password": "c29tZV9wYXNzd29yZA=="
}

• Then, I installed the Bitnami Valkey chart configuring it to use the existing secret:

helm install valkey oci://registry-1.docker.io/bitnamicharts/valkey --set auth.existingSecret=my-valkey-secret --set auth.existingSecretPasswordKey=password

• Finally, I followed the installation notes to create a client a connect to Valkey and set some key:

$ kubectl run --namespace default valkey-client --restart='Never'  --env VALKEY_PASSWORD=some_password --image docker.io/bitnami/valkey:8.0.2-debian-12-r0 --command -- sleep infinity
$ kubectl exec --tty -i valkey-client --namespace default -- bash
I have no name!@valkey-client:/$ REDISCLI_AUTH="$VALKEY_PASSWORD" valkey-cli -h valkey-primary
valkey-primary:6379> set foo bar
OK
valkey-primary:6379> get foo
"bar"
valkey-primary:6379> exit
I have no name!@valkey-client:/$ REDISCLI_AUTH="$VALKEY_PASSWORD" valkey-cli -h valkey-replicas
valkey-replicas:6379> get foo
"bar"

[franz-dalitz]

i don't know what to make of this, maybe it's a problem with kustomize-helm interactions then...

[juan131]

@franz-dalitz are you positive the password was properly base64-encoded when creating the secret? This is a common issue.

[franz-dalitz]

i am, as described i can even verify that the password is present as an environment variable via printenv

[franz-dalitz]

just verified my error once more to make sure i'm not confused. did everything from before again, wiped the pvs once more, confirmed the password is in the env vars via printenv, yet it doesn't work.

[juan131]

Hi @franz-dalitz

I'm afraid I'm not able to reproduce the issue and I don't really know what could be wrong based on what you shared. Could you try creating the secret using the kubectl command below? Please update the XXXXX with whatever password you want to use:

kubectl create secret generic valkey --namespace dev --from-literal=password=XXXXX

[franz-dalitz]

doing that it works just fine, that's weird... i am absolutely certain what i used was encoded base64 just fine, when i sent it through base64 -d it came out exactly as it was supposed to.

[franz-dalitz]

i suppose i can close this then, thank you for your help, i appreciate your time very much

[juan131]

I'm glad you were able to solve the issue!