ConfigMaps and Secrets

Two objects, same shape: a data field of key-value strings. ConfigMap for non-sensitive config, Secret for sensitive. The only real difference is conventions and tooling around encryption.

How you consume them

Three ways to inject into a Pod:

• Env vars: envFrom: configMapRef or per-key valueFrom. Snapshot at Pod start. Updates do NOT propagate.
• Volume mount: file per key in a directory. The kubelet updates the file on the next sync (~60s) when the source changes.
• Subpath mount: mount a single key as a file. No auto-update.

Secrets are not encrypted by default

base64(password) in etcd. Anyone with API access or etcd access reads them. Three steps to make Secrets actually safe:

1. Enable encryption at rest for Secrets in the API server (KMS provider, AWS KMS on EKS).
2. Lock down RBAC so only specific service accounts read specific Secrets.
3. Audit log Secret reads.

The pattern that actually works

Do not store production secrets as raw Kubernetes Secrets in Git. Use External Secrets Operator (ESO) to sync from AWS Secrets Manager, Vault, GCP Secret Manager, or Azure Key Vault. ESO creates/updates the Kubernetes Secret from the external source on a schedule. Source of truth lives where rotation and audit are first-class.

Immutability

Set immutable: true on a ConfigMap or Secret to prevent updates. This is good for two reasons: it stops accidental edits, and the kubelet does not need to watch it for changes (less API server load at scale).

The interview answer

ConfigMaps and Secrets are key-value stores mounted as env vars or files. Env vars are a snapshot, volume mounts auto-update. Default Secrets are base64-encoded, not encrypted - production needs KMS encryption at rest and a secret manager (AWS Secrets Manager + ESO) as the source of truth.