I'm planning to wrap our application (which consists of multiple microservices) into a chart.
Right now, for each microservice, we store secrets and configuration values hardcoded directly in our deployment.yaml files, in ...containers[].env. All of our yaml files are stored in git repo.
I have noticed that some popular charts use ConfigMap (1, 2) and Secret (1, 2) Kubernetes objects to store config values and secrets respectively.
What are some advantages, be it ergonomics and/or security gains, of using ConfigMap and Secret objects?
I could already make templates out of all yaml files we have, making all hardcoded values configurable and thus resolvable during helm's template compilation time.
However, since Kubernetes provides specialized objects to store configuration & secrets, I want to justify adding configmap.yaml and secrets.yaml template files, as well adding references to them from existing deployment.yaml files.
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 nginx.conf in a configmap and load it in the proper location for the nginx daemon to read it.
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 v1.7
You can set environment variables in your deployment manifest to point to specific values in secrets or configmaps. Both are also easily generated with kubectl for example:
kubectl create secret generic foobar --from-literal=password=foobarkubectl create configmap foobar --from-file=foobar.confHelm charts best practice is to use both, see mariadb chart.
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.