-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Updating the helm chart version forces plaintext DB password #89
Comments
Well, slight update: if one uses the I'm not entirely sure this has other side effects, but did not seem to be the case for the simple case at the very least. I'll leave the issue open so that all facts can be brought to light. Maybe this was intentional? I'm not fully sure. I'd be happy to help w/ reproducing the issue or even a fix if this is considered to be a bug. |
Hi @conilas, the postgres functionality can be quite tricky as there are bits of logic we do in the chart (which you've linked) but there's also some quirks to the way the underlying Postgres sub-chart that we're using. Have you had a look into bitnami/charts#16417 ? As when you upgrade, it tries to generate the password, instead try to get the password and create your own secret with it in, and reference it in the Chart? |
Hello there!
So it seems that I've run into a conundrum.
When first installing the helm chart, i.e by simply:
The postgresql instance is created, a secret is generated and the deployment points to that secret. Perfect!
However, at a later stage, when I try to do a
helm diff upgrade pact-broker pact-broker/pact-broker --version 1.1.0
(for example), one gets an error at first:Makes sense: the password has to be provided.
However, if I do provide the password (either via values file or via
--set postgresql.auth.password=$(kubectl get secret --namespace "observability" pact-broker-postgresql -o jsonpath="{.data.user-password}" | base64 -d)
), the diff will be something like:meaning that my deployment will be overriden and it will stop looking for the secret and go directly for a plaintext password, which is clearly unintended.
To my understanding this is related to how this part is being run.
That is to say, if one needs to provide the password and then the template will use that value if provided, it seems impossible to maintain the variable set to a secret value when upgrading versions.
Seems like this is a bug?
The text was updated successfully, but these errors were encountered: