-
Notifications
You must be signed in to change notification settings - Fork 1.3k
[Helm chart] Configuring sensitive values via secrets #3094
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
Comments
That makes perfect sense. We could adopt a pattern akin to how we handle the HTTPS certificates, except that one could still provide the value directly if necessary, e.g.: server:
sessionSecret:
secretName: some-preexisting-secret
key: data-in-the-secret but also: server:
sessionSecret:
value: "enter value here directly" We would do that for:
|
Thanks you for considering this feature! You can even autogenerate those if you are willing to drop / have dropped Helm 2 support: https://github.com/helm/charts/issues/5167#issuecomment-619137759 |
- I fetch values via Helm `lookup` calls. This is Helm 3 only compatible. - I do not alter the templates to use the existing secrets, I fetch from them and let gitpod create (possibly redundant) secrets - serverProxyApiKey / db.password / components.server.sessionSecret can be set, added via secret with arbitrary key and are autogenerated otherwise - rabbitmq secret can be set, assuming username and password are keys in the secret - nothing is done for minio secrets because it is a subchart with a April 2021 deprecation warning
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Hi,
Would it be possible to set the sensitive values in the Helm chart (like
components.server.sessionSecret
for ex., but also db password and oauth info) via either anexistingSecret
secret reference or setting an environment variable?Right now the
values.yaml
has sensitive information in it which is an issue for “gitops-style” management of Kubernetes.Thanks!
The text was updated successfully, but these errors were encountered: