ConfigMaps hold settings, Secrets hold credentials, and neither belongs in the image.

The same image runs in every environment because configuration is injected at runtime as environment variables or mounted files.

ConfigMap

plain text

kind: ConfigMap
metadata: {name: checkout-config}
data:
  LOG_LEVEL: info
  app.properties: |
    currency=EUR
    retries=3

Non-sensitive settings and whole config files. Up to about 1 MiB per object.

Secret

base64, not encrypted

kind: Secret
type: Opaque
metadata: {name: payments-db}
data:
  password: c2VjcmV0LXZhbHVl   # base64
# anyone who can read it can decode it

Same API, but access is controlled separately with RBAC and it can be encrypted at rest in etcd.

As environment variables

envFrom or valueFrom. Simple, but read only at container start.

As mounted files

A volume under /etc/config. Updates reach the files without a restart (after a short delay).

Real secret management

Prefer an external store (Secret Manager, AWS Secrets Manager, Vault) synced by an operator or CSI driver.

Keep configuration out of the image

The twelve-factor principle is to keep configuration out of the build artifact so one image can be promoted from staging to production unchanged. Kubernetes gives you two objects for this. A ConfigMap stores non-sensitive settings, either as individual keys or as whole files. A Secret has the same shape but is intended for credentials, tokens and certificates, and has its own RBAC and optional encryption at rest.

The most important fact is that a Secret is base64 encoded, not encrypted, by default. Base64 is a transport encoding anyone can reverse. Real protection comes from three things: tight RBAC so few identities can read Secrets, encryption at rest for etcd (managed clusters usually offer this with a cloud KMS key), and, best of all, not storing the source of truth in the cluster at all by syncing from an external secret manager.

You consume both in two ways. Environment variables are simple but are fixed when the container starts, so changing the ConfigMap requires a rollout. Mounted files are refreshed by the kubelet after a delay, which suits applications that reload config; note that subPath mounts do not update.

Gotcha: committing Secret manifests to Git exposes them to anyone with repository access. Use sealed or external secrets, which Deck 5 covers.