ConfigMap and Secret

How it works

A ConfigMap stores non confidential configuration as key value pairs. A Secret is a similar object intended for sensitive data such as passwords, tokens and keys. Both keep configuration out of container images, so the same image can run in development, staging and production with different settings. This follows the Twelve-Factor App principle of storing config in the environment.

Pods can consume either object in several ways: as environment variables, as files in a mounted volume, or as command line arguments through environment variables. Files from mounted volumes are refreshed by the kubelet after a delay when the object changes, whereas environment variables are fixed when the container starts, so a restart is needed to pick up new values. Mounts that use subPath do not receive updates.

An important point about Secrets: values in the data field are base64 encoded, which is an encoding and not encryption. Kubernetes documentation states that Secrets are stored unencrypted in etcd by default, so you must enable encryption at rest (via an EncryptionConfiguration) and restrict access with RBAC.

A practical example

A ConfigMap and a pod that reads one key from it as an environment variable:

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  LOG_LEVEL: "info"
---
apiVersion: v1
kind: Pod
metadata:
  name: demo
spec:
  containers: [{name: app, image: example/app:1.0, env: [{name: LOG_LEVEL, valueFrom: {configMapKeyRef: {name: app-config, key: LOG_LEVEL}}}]}]

A Secret is consumed in the same way using secretKeyRef. The image name here is a placeholder.

Common mistakes

• Believing base64 is protection, and committing Secret manifests to Git in plain form.
• Putting secrets in a ConfigMap because it is simpler.
• Letting many people or service accounts read Secrets. Anyone who can create a pod in a namespace can usually read that namespace’s Secrets indirectly.
• Expecting environment variables to update when a ConfigMap changes.
• Not enabling encryption at rest on self managed clusters, and not checking the setting on managed ones.

When to use it and when not to

Use ConfigMaps for non sensitive settings and Secrets for small sensitive values, combined with RBAC and encryption at rest. For stronger practice, store the source of truth in an external secrets manager and sync it into the cluster, or use encrypted manifests such as Sealed Secrets. Very large or binary data does not belong in either object.

Related reading: Kubernetes and RBAC. See our Sealed Secrets and External Secrets Operator page.

See also

• Kubernetes
• Sealed Secrets
• RBAC