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

<p>Currently, I hava a configuration.yaml file, where I do all the configurations and over <code>microk8s.helm install -f configuration.yaml --name=prod repo.k8s/product</code>. 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.</p>

<p>Second approach would be to deploy the secrets and the certificates separate using the <code>kubectl</code> and then just reference the secrets in the helm chart. It seems to be a common used approach: <a href="https://github.com/helm/charts/search?q=existingSecret&amp;unscoped_q=existingSecret" rel="nofollow noreferrer">https://github.com/helm/charts/search?q=existingSecret&amp;unscoped_q=existingSecret</a></p>

<p>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: <a href="https://github.com/aws-samples/aws-workshop-for-kubernetes/tree/master/04-path-security-and-networking/401-configmaps-and-secrets" rel="nofollow noreferrer">https://github.com/aws-samples/aws-workshop-for-kubernetes/tree/master/04-path-security-and-networking/401-configmaps-and-secrets</a></p>

aphex
<p>Here are the <a href="https://helm.sh/docs/howto/charts_tips_and_tricks/" rel="nofollow noreferrer">official Best Practices</a> as defined by Helm themselves which answers many and more of the questions that you did yourself.</p>
<p>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 <a href="https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/" rel="nofollow noreferrer">encrypted etcd at rest</a> and configured <a href="https://kubernetes.io/docs/reference/access-authn-authz/rbac/" rel="nofollow noreferrer">Role Based Access Control</a> 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 <a href="https://www.vaultproject.io/" rel="nofollow noreferrer">Hashicorp Vault</a> or <a href="https://aws.amazon.com/blogs/aws/aws-secrets-manager-store-distribute-and-rotate-credentials-securely/" rel="nofollow noreferrer">AWS Secrets Manager</a>.</p>
