<p>I'm planning to wrap our application (which consists of multiple microservices) into a chart.</p>

<p>Right now, for each microservice, we store secrets and configuration values hardcoded directly in our <code>deployment.yaml</code> files, in <code>...containers[].env</code>. All of our <code>yaml</code> files are stored in git repo.</p>

<p>I have noticed that some popular charts use <code>ConfigMap</code> (<a href="https://github.com/kubernetes/charts/blob/master/stable/grafana/templates/configmap.yaml" rel="nofollow noreferrer">1</a>, <a href="https://github.com/kubernetes/charts/blob/master/stable/mariadb/templates/configmap.yaml" rel="nofollow noreferrer">2</a>) and <code>Secret</code> (<a href="https://github.com/kubernetes/charts/blob/master/stable/jenkins/templates/secret.yaml" rel="nofollow noreferrer">1</a>, <a href="https://github.com/kubernetes/charts/blob/master/stable/drupal/templates/secrets.yaml" rel="nofollow noreferrer">2</a>) Kubernetes objects to store config values and secrets respectively.</p>

<p><strong>What are some advantages, be it ergonomics and/or security gains, of using <code>ConfigMap</code> and <code>Secret</code> objects</strong>?</p>

<p>I could already make templates out of all <code>yaml</code> files we have, making all hardcoded values configurable and thus resolvable during helm's template compilation time.</p>

<p>However, since Kubernetes provides specialized objects to store configuration &amp; secrets, I want to justify adding <code>configmap.yaml</code> and <code>secrets.yaml</code> template files, as well adding references to them from existing <code>deployment.yaml</code> files.</p>

<p>Configmaps are very generic configuration files. They can consist of a list of key value pairs but they can also be generic files. For example you can store a nginx configuration file <code>nginx.conf</code> in a configmap and load it in the proper location for the nginx daemon to read it.</p>

<p>Secrets are supposed to be used for storing sensitive data, unfortunately right now secrets are not encrypted, they are just based64 encoded. So while this helps you remove hardcoded non-encrypted values from your manifests, it does not help with encryption at all. This should get better in <a href="https://github.com/kubernetes/features/issues/92" rel="nofollow noreferrer">v1.7</a></p>

<p>You can set environment variables in your deployment manifest to point to specific values in <a href="https://kubernetes.io/docs/concepts/configuration/secret/#using-secrets-as-environment-variables" rel="nofollow noreferrer">secrets</a> or <a href="https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#using-configmap-defined-environment-variables-in-pod-commands" rel="nofollow noreferrer">configmaps</a>. Both are also easily generated with <code>kubectl</code> for example:</p>

<ul>
<li><code>kubectl create secret generic foobar --from-literal=password=foobar</code></li>
<li><code>kubectl create configmap foobar --from-file=foobar.conf</code></li>
</ul>

<p>Helm charts best practice is to use both, see <a href="https://github.com/kubernetes/charts/tree/master/stable/mariadb/templates" rel="nofollow noreferrer">mariadb chart</a>.</p>

<p>Personally, when I need to load a file in a Pod I use a configmap, and when I deal with a sensitive env variable I use a secret, keeping in mind that it is not encrypted.</p>
