Generate passwords etc. into a dedicated k8s Secret that can be re-used

[cyrilcros]

Proposed change

Split hub-secret into two different secrets, one containing the values.yaml key and generated from the Helm config, the other would hold the proxy.token and cookie.secret and can be set via existingSecret.

Following commit 8fab275 , the values.yaml are pulled into the secret. That’s an annoyance if you are trying to manage secrets encrypted in version control via Mozilla SOPS or Bitnami SealedSecrets. Ideally, you would like not to have to re-encrypt every single innocuous change to the values.yaml and instead keep it free of any sensitive content, so it can go into version control as clear text.
That’s also a potential breaking change for users who upgrade the chart, since the existingSecret needs to be replaced. It is also annoying not be able to have direct access to your values in git.

Alternative options

Who would use this feature?

Anyone using the existingSecret option / using similar Gitops tools to manage Secrets.

(Optional): Suggest a solution

See proposed changes

Take this file:

• always create no matter what a hub-secret Secret with lines 10-16 and if and only if existingSecret doesn’t exist add lines 18-35 to that secret (move line 1 to line 17)
• switch the templates secretKeyRef to {{hub-secret}} and only use {{ .Values.hub.existingSecret | default "hub-secret" }} for proxy.token and other keys from lines 18-35
• switch the templates condition; instead of using only hub.db.password add a .Values.hub.db.existingSecretHoldsPassword Boolean flag. A line like

  zero-to-jupyterhub-k8s/jupyterhub/templates/hub/deployment.yaml

  Line 171 in 605cebc

  {{- if .Values.hub.db.password }}

  becomes {{- if or .Values.hub.db.password .Values.hub.db.existingSecretHoldsPassword}}
• if you still want to keep the possibility to encrypt the values.yaml, add a new Boolean option Values.hub.existingSecretHoldsEncryptedValues and use that as the ‘ if condition’ on line 1. Users should then call their secret hub-secret, or better the Chart could use a user supplied variable allowing other secret name than hub-secret

[consideRatio]

Note that this issue is closely related to #1017 where I realized we can make use of the ideas in https://github.com/helm/charts/issues/5167#issuecomment-619137759. The latter describes the technical implementation of generating a secret that can be re-used with helm without introducing dedicated in-k8s-pod logic. This suggests the idea that when we generate the secret content, that we would also split the secret in two to make it easier to reference an old version of the autogenerated parts. I think it is a great idea!

Following commit 8fab275 , the values.yaml are pulled into the secret. That’s an annoyance if you are trying to manage secrets encrypted in version control via Mozilla SOPS or Bitnami SealedSecrets. Ideally, you would like not to have to re-encrypt every single innocuous change to the values.yaml and instead keep it free of any sensitive content, so it can go into version control as clear text.

You can use two separate files, secret-values.yaml and values.yaml, but your request is relevant anyhow. It would be nice if you simply didn't provide proxy.secretToken etc manually through Helm values, but instead generated them and kept the generated ones in the k8s cluster under a default name or allowed the user to point to previously generated values in another Helm secret resource. I think we should do this, but, only when we drop support entirely for Helm2 users, which may be a good thing to do about now because today Helm2 reached end of life.

Thank you for your thorough write-up @cyrilcros ❤️