How best to call Hashicorp Vault's REST API from Jupyterhub to retrieve the Jupyterhub database password and TLS certs

JupyterHub Zero to JupyterHub on Kubernetes
,
1

We are deploying Z2JK on the Google Cloud.

My company has a policy that database passwords and TLS certs need to be stored in a secrets vault – in our case that is Hashicorp’s Vault product. Furthermore, applications need to dynamically access the secret vault (Hashicorp Vault) whenever they require access to database passwords and TLS certs. Using K8s secrets and environment variables to store database passwords and TLS certs is not allowed.

The question I have is what is the best way to implement this requirement in Jupyterhub.

One obvious – but not desirable – option is to add code to the Hub’s extraConfig section of the Value.yaml file to retrieve the Jupyter data base password and its TLS certs from Hashicorp Vault via REST API and set these values into Jupyterhub’s traitlets. I am not fond of this option because it is difficult to perform automated unit testing, code coverage and regression testing against code written in the Hub’s extraConfig section of the Values.Yaml file.

Another option is to identify an existing Jupyterhub python class (and .py file) that we can subclass or replace to add that will allow us to invoke Vault’s REST API and set Jupyterhub’s traitlets when Jupyterhub is initializes it connection to the Jupyter data base.

Will appreciate suggestions from the community how to best accomplish this objective – dynamically invoking Hashicorp in Jupyterhub when it initializes its connection to the Jupyter database.

Best wishes,

mark berman

2

I think extraConfig makes sense. However if you want to test the code independently you could put all the helper methods into a new Python file/module, rebuild your hub Docker image with that module, and import that module in extraConfig.

3

I would consider creating an initcontainer. This time you need it in jupyterhub using python codeand allowing you to inject it with custom python code, but soon you will add something where you want to do the same for a container where you cant i figure.

So, using a dedicated init container to fetch and store a cert somewhere in a emptyVolume shared between both containers seems like the sustainable strategy.

4

We are exploring vault-k8s (GitHub - hashicorp/vault-k8s: First-class support for Vault and Kubernetes.) as a “look ma, no code required” solution. Will keep everyone on this forum updated with our status.

If “vault-k8s” is not an option, will definitely go down the initContainer route for the hub pod.