-
Notifications
You must be signed in to change notification settings - Fork 795
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
Automatic creation of random proxy.secretToken #1017
Comments
👍 Only thing I'd like is that it plays well with the |
"the first time" - as when helms flag .Release.IsInstall (or something like this) is truthy? How is a secret generated by helm but not used? Is the secret read and stored someplace else by a pod? Hmmm... I know one could use a helm hook to create a secret once on install and later not generate it ( i think this solution is almost ok, a bit too many drawbacks ) though. What would it mean to play well with the helm diff command, can you examplify? I have not used this plugin (its a plugin?) |
Absolutely! We investigated this early on and I thought it wasn't possible (what we found regenerated the secrets on every |
Here's an issue about it: https://github.com/helm/charts/issues/5167 |
@consideRatio helm diff is a plugin which effectively gives you a diff of the generated templates. I've found it quite useful when managing multiple helm deployments with helmfile. The Grafana Helm chart regenerates the secret on every run, but it's only used by Grafana the first time to set the admin password which is then saved in persistent storage, so on future updates Grafana ignores the changed secret. |
Tools of relevance summarized:
Best idea currently i have (failing):
Idea snippets:
|
Perhaps we use an operator?
See this kubecone talk: https://www.youtube.com/watch?v=8k_ayO1VRXE |
I've considered this in the back of my mind for ages, and there are some options, but I don't like them enough to suggest we do it. But, I think the best option could be to create a Secret resource that is only installed as a helm hook that is triggered on install, as compared to on upgrade, which is possible for Helm to know during template rendering. As Helm hook resources won't be managed by Helm following they are created, it will remain and not be deleted even though it doesn't render when Oh, yeah, this is the idea I had two years ago described above. |
OH! When we assume Helm3, we could perhaps consider this: https://github.com/helm/charts/issues/5167#issuecomment-619137759 |
Closing this in favor of #1910, the implementation technique will be like this: https://github.com/helm/charts/issues/5167#issuecomment-619137759 |
It would be great to not ask the admins (those installing this helm chart) to manually set keys, but instead let them be set automatically. It adds a lot of initial complexity to get things started.
The GitLab helm chart has automated this for example: https://gitlab.com/charts/gitlab, i have not looked into how in detail yet.
The text was updated successfully, but these errors were encountered: