How am I supposed to use `existingSecret`

JupyterHub Zero to JupyterHub on Kubernetes
, ,
#1

Hi!

I am deploying JupyterHub on a Kubernetes cluster. The authentication is done using Azure AD.
The config.yaml is version controlled in Git, and I would like to get rid of any references to the AzureAD client secrets. That is

auth:
  azuread:
    callbackUrl: ...
    clientId: ...
    clientSecret: ...
    tenantId: ...

type: azuread

I have tried to navigate previous posts on this issue, to no avail. I know of the concept of existingSecret, however there are no references to how exactly you are supposed to use this.

Could anyone provide some insight on how I can expose the AzureAD authentication secrets as a kubernetes secret, to avoid having to commit this to VCS?

Cheers in advance :smile:

#2

I don’t know about existingSecret, but I stored my secrets in an Azure Key Vault, then used an Azure Pipeline to populate my config file and upgrade the cluster when I pushed to the default branch: https://www.github.com/alan-turing-institute/hub23-deploy/tree/main/.az-pipelines%2Fcd-pipeline.yml (This is for a BinderHub, but it’s dependent on the z2jh-k8s chart).

More documentation here: https://alan-turing-institute.github.io/hub23-deploy

1 Like
#3

Thanks for the tips! I’ll take a look.

I’d still love some advice on the existingSecret, which was introduced in Z2JH 0.9, if I recall correctly.

#4

The configuration reference includes a cautionary note.

NOTE: if you choose to manage the secret yourself, you are in charge of ensuring the secret having the proper contents.

We merged this PR, but my personal opinion is that it was introducing something that we can’t really maintain and will lead too quite a bit of complexity for users to use it.

I want to make it sustainable to use, but in my mind, it currently isn’t. One need to make sure the content is updated at all time with a lot of configuration that change between versions and your own configuration in general. Doing that in turn requires a lot of what I consider unsustainable maintenance such as helm template <...> --show-only templates/hub/secret.yaml --set hub.existingSecret="" which you then manually apply in your k8s cluster to some k8s secret, and then you update your hub.existingSecret to reference that again.

Making this sustainable is something reflected in this issue:

1 Like
#5

I’ve now opened an PR to make use of hub.existingSecret more sustainable, see: