ConfigMap Theory

Kubernetes provides an object, called a ConfigMap (CM), that lets you store configuration data outside of a Pod. It also lets you dynamically inject the data into a Pod at runtime.

Note: When we use the term Pod we mean the Pod and all of its containers. After all, it is ultimately the container that receives the configuration data.

ConfigMaps are first-class objects in the Kubernetes API under the core API group, and they’re v1. This tells us a lot of things:

1. They’re stable (v1).
2. They’ve been around for a while (the fact that they’re in the core API group).
3. You can operate on them with the usual kubectl commands.
4. They can be defined and deployed via the usual YAML manifests.

ConfigMaps are typically used to store nonsensitive configuration data such as:

• Environment variable values
• Entire configuration files (things like web server configs and database configs)
• Hostnames
• Service ports
• Account names

You should not use ConfigMaps to store sensitive data, such as certificates and passwords. Kubernetes provides a different object, called a Secret, for storing sensitive data. Secrets and ConfigMaps are very similar in design and implementation, the major difference is that Kubernetes takes steps to obscure the values stored in Secrets. It makes no such efforts to obscure data stored in ConfigMaps.