Zero-to-jupyterhub-k8s: Automatic creation of random proxy.secretToken

[consideRatio]

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.

[manics]

👍 Only thing I'd like is that it plays well with the helm diff plugin. The Grafana helm chart auto-generates a secret for the admin password if one isn't specified. This secret is only used the first time (so existing admin password isn't overwritten), but everytime you run the helm chart it still regenerates a different secret which means helm diff always shows a difference.

[consideRatio]

"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?)

[minrk]

Absolutely! We investigated this early on and I thought it wasn't possible (what we found regenerated the secrets on every helm upgrade, if I recall, which wouldn't be good enough). If someone finds a way, this is definitely what we should do.

[minrk]

Here's an issue about it: https://github.com/helm/charts/issues/5167

[manics]

@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.

[consideRatio]

@minrk

Tools of relevance summarized:

1. Helm hook allows for creation of unmanaged resources by helm, they will be created and then ignored - there will be managed helm hooks in the future though.
2. Helms built in object .Release.IsInstall: This is set to true if the current operation is an install.

Best idea currently i have (failing):

• We could use a helm hook wrapped in {{- if .Release.IsInstall }} to create a secret only once, and we could make sure to fail install early if this secret already exist to avoid overwriting the previous secret if a reinstall of the chart takes place. The challenges of this is to create the secret using the existing helm template helpers, and also to be compatible with preexisting installs.

Idea snippets:

• We may not need to keep utilizing the data in a secret or similar.
• We may use a init_container to inject secrets, this is something I think GitLab does to accomplish some other benefits.
• We could use some operator (a pod running, communicating with the k8s API) doing things intelligently with custom logic.

[consideRatio]

Perhaps we use an operator?

• "Is there a secret available? No? Lets create one!"

See this kubecone talk: https://www.youtube.com/watch?v=8k_ayO1VRXE
And this reference stuff: https://github.com/operator-framework/operator-sdk

[consideRatio]

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 helm upgrade is run later.

Oh, yeah, this is the idea I had two years ago described above.

[consideRatio]

OH! When we assume Helm3, we could perhaps consider this: https://github.com/helm/charts/issues/5167#issuecomment-619137759

[consideRatio]

Closing this in favor of #1910, the implementation technique will be like this: https://github.com/helm/charts/issues/5167#issuecomment-619137759