Best practices for secrets in Z2JH deployments

This is a bit of a newbie question – I’m setting up a Z2JH deployment, and I’d like to have as much of the configuration in version control as possible. Much of the config.yaml should be considered public information, but some if it is not (cookies, client secrets, etc). So I am looking for some recommendations around the following

  1. What are considered best-practices around keeping these configurations in version control?
  2. Is there a way to break some of this data into separate files that can be encrypted (e.g., using git-crypt), and then assemble them into a single config upon deployment?


helm can take multiple config files at the command line which are merged together, so you could have one public config file, and a separate private config file which you decrypt/copy/store elsewhere:

helm install ... -f public.yml -f path/to/private.yml uses git-crypt and is deployed by travis:

Whereas the IDR which I work on uses gitlab-ci for the deployment, and secrets are stored as secret GitLab environment variables


Another option worth considering is sops - it allows you to have everything in one repo and keeps the keys plaintext while encrypting the values so the yaml is still readable/understandable even if the values are not.

1 Like Is a detailed analysis we did of various options. Might be useful.

1 Like

I’ve been lurking on that thread, lots of useful info indeed!

Thanks for the thoughts, all!