Best practices passing configurations,certificates and secrets with helm install

3/20/2020

Are there any recommendations how to pass configuration, certificates and some secrets with helm install?

Currently, I hava a configuration.yaml file, where I do all the configurations and over microk8s.helm install -f configuration.yaml --name=prod repo.k8s/product. There the user can configure everything including some credentials. I store the credentials in the secret store. I could pass the certificates also in the configuration.yaml and copy their content there. It doesn't look really nice, but it will work.

Second approach would be to deploy the secrets and the certificates separate using the kubectl and then just reference the secrets in the helm chart. It seems to be a common used approach: https://github.com/helm/charts/search?q=existingSecret&unscoped_q=existingSecret

Third approach is to use vaults for the credentials. What is your experience with it? Do you use it? There is a tutorial for them here: https://github.com/aws-samples/aws-workshop-for-kubernetes/tree/master/04-path-security-and-networking/401-configmaps-and-secrets

-- aphex
kubernetes
kubernetes-helm

1 Answer

3/28/2020

Here are the official Best Practices as defined by Helm themselves which answers many and more of the questions that you did yourself.

In general, it is best to decouple application code, configuration, and secrets when possible. This is why Kubernetes has dedicated resource types to each of this concepts. Continuing on from there, you should make sure you have enabled encrypted ecd at rest and configured Role Based Access Control to properly ensure that nothing can read your Secret resource data unless it has the proper permissions. Some people take this a step further and provision decentralized secret stores that they make API calls to on-demand instead of reading from within the API Server. Such as Hashicorp Vault or AWS Secrets Manager.

-- TJ Zimmerman
Source: StackOverflow