ConfigMaps and Secrets

A ConfigMap holds non-sensitive configuration; a Secret holds sensitive data such as passwords or tokens, structured the same way. Both are consumed the same two ways: as an environment variable (env[].valueFrom.configMapKeyRef or secretKeyRef) or as a mounted volume, where each key becomes a file. Neither storage mechanism is exclusive to sensitivity level — a Secret is simply the object Kubernetes treats as sensitive by convention and tooling, not one that's cryptographically protected on its own.

That last point matters more than it sounds: Secret values are base64-encoded, not encrypted. Base64 is a reversible encoding, not a cipher — anyone with API read access to a Secret can decode it in one command. Genuine protection comes from RBAC controlling who can read the Secret at all, plus, if needed, separately configuring encryption at rest for etcd.

env:
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: db-credentials
        key: password
volumeMounts:
  - name: db-creds
    mountPath: /etc/db-credentials
    readOnly: true
volumes:
  - name: db-creds
    secret:
      secretName: db-credentials

Update behavior differs sharply by consumption method. A ConfigMap or Secret consumed as an environment variable is fixed at container start — changing the object later has no effect until the Pod is restarted. One consumed as a volume mount updates eventually: the kubelet checks freshness on its periodic sync, so the total delay is roughly the sync period plus a cache propagation delay. A container using a ConfigMap or Secret as a subPath volume mount never receives updates at all, regardless of how long you wait.

Setting immutable: true on a ConfigMap or Secret — stable since Kubernetes v1.21 — locks its data permanently: the flag itself cannot be reverted, and the data cannot be edited afterward. The only way to change it is to delete and recreate the object, and since existing Pods keep their old mount point, those Pods should be recreated too.