ConfigMaps and Secrets

ConfigMaps hold non-confidential configuration and Secrets hold sensitive values, both decoupled from the container image. The same image runs in dev, staging, and prod; only the ConfigMap and Secret change. This is the twelve-factor principle of config-in-the-environment made concrete.

The dangerous misconception to clear up immediately: a Secret is not encrypted. It is base64-encoded, which is encoding, not security. Treating Secrets as genuinely secret requires extra work, covered here and in depth in the security chapter.

ConfigMaps

A ConfigMap is a set of key-value pairs — individual values or whole config files. You consume it two ways: as environment variables injected into a container, or as files mounted into a volume. The choice matters for updates, as the next section explains.

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  LOG_LEVEL: info
  config.yaml: |
    server:
      timeout: 30s

Env Vars vs Volume Mounts

How you consume config changes its update behavior. Values injected as environment variables are read once at container start and never change — updating the ConfigMap does nothing until the Pod restarts. Values mounted as files in a volume are updated in place when the ConfigMap changes (after a short delay), so an app that re-reads the file can pick up changes live. Neither restarts your process for you; the app must either be restarted or watch the file.

This trips people up constantly: they edit a ConfigMap, see the env-var-based app keep using the old value, and assume something is broken. Choose volume mounts when you want live reload, and accept that env vars are effectively immutable for the Pod's lifetime.

Secrets and Why They Aren't Secret

A Secret looks like a ConfigMap but is meant for sensitive data, and Kubernetes treats it slightly differently — it is not written to a Pod's environment in logs, and is held in memory on nodes rather than on disk. But the values are merely base64-encoded, which anyone can decode. By default a Secret sits in etcd in plaintext, and anyone with read access to Secrets in a namespace can read it.

Making Secrets actually secure takes three things, covered fully in the security chapter: enable encryption at rest so etcd does not store plaintext, lock down RBAC so few identities can read Secrets, and consider an external secret store (Vault or a cloud secrets manager) so the sensitive value never lives in etcd at all.

Immutability and Good Hygiene

Marking a ConfigMap or Secret immutable: true prevents accidental edits and lets the kubelet stop watching it, which improves performance at scale. The common pattern is to create a new, versioned ConfigMap per change and update the Deployment to reference it — which also makes the config change a tracked, rollback-able part of the deploy rather than an invisible live edit.