ConfigMap & Secret
The same code has to behave differently in development and in production. Bake the values into the image and the code stays identical while the images multiply — one per environment, rebuilt for every value you change. Move the settings into a ConfigMap and a Secret and one image is enough; the values are laid on as environment variables or files when the Pod starts.
01ConfigMap & Secret
Concept at a GlanceThe same code has to behave differently per environment. Bake the values into the image and the code stays identical while the images multiply.
Change one value and you rebuild and redeploy. Worse, the password now sits inside the image, where anyone who pulls it can read it.
Pull the settings out and you are back to a single image. The values live in a ConfigMap as plain keys and values.
There are two ways to attach them. One is environment variables — the values are stamped into the process as the container starts.
The other is a volume mount. The values show up as files, so a whole configuration file can go in as it is.
The two differ on updates. Edit the ConfigMap and the mounted file follows a moment later, while an environment variable does not — the Pod has to start again.
What changes the environment is the config you attach, not the image. Attach prod values to that same v1 and the Pod runs as prod.
Passwords go in a Secret rather than a ConfigMap. Keeping them apart is what lets you decide separately who may read them.
A Secret is only base64-encoded, though — that is not encryption. Without encryption at rest and RBAC, the value reads straight back out.
02 Understand It Simply
For EveryoneValues that differ per environment are pulled out of the image into ConfigMaps and Secrets. Injected as environment variables they require a restart to change; mounted as a volume the files update shortly after.
A ConfigMap is a bundle of key-value pairs, given to a Pod either as environment variables or mounted as a volume that shows them as files.
The two differ on updates: a mounted file follows an edit to the ConfigMap a moment later (the app still has to re-read it), while environment variables are stamped in at container start and don't change until the Pod restarts.
A Secret is used the same way, but its values are merely base64-encoded rather than encrypted, so access has to be closed off separately with encryption at rest and RBAC.
Beyond these two, values can also arrive as container command-line arguments or be read straight from the API by the app.
- –Moving per-environment settings out of the image
- –choosing between env vars and mounts
- –judging whether a config change needs a restart
- –and separating sensitive values into Secrets with their own access rules
03 Frequently Asked Questions
FAQWhat is ConfigMap & Secret?+
The same code has to behave differently in development and in production. Bake the values into the image and the code stays identical while the images multiply — one per environment, rebuilt for every value you change. Move the settings into a ConfigMap and a Secret and one image is enough; the values are laid on as environment variables or files when the Pod starts.
Where is ConfigMap & Secret used?+
Moving per-environment settings out of the image, choosing between env vars and mounts, judging whether a config change needs a restart, and separating sensitive values into Secrets with their own access rules.
What's a simple analogy for ConfigMap & Secret?+
Values that differ per environment are pulled out of the image into ConfigMaps and Secrets. Injected as environment variables they require a restart to change; mounted as a volume the files update shortly after.