ConfigMaps and Secrets: how do they differ, and how should secrets really be handled?

Summary

Both hold configuration that pods consume as environment variables or mounted files. Secrets are intended for sensitive data, but by default they are only base64-encoded, stored in etcd, and readable by anyone with get secrets permission in the namespace.

Longer Answer

Harden secrets: enable encryption at rest for etcd (managed services often use a KMS provider), restrict RBAC on secrets tightly (listing secrets is as good as reading them), avoid environment variables for very sensitive values (they leak into crash dumps and child processes; mounted files can also be rotated), and source secrets from a manager (AWS Secrets Manager, Vault, Google Secret Manager) through the External Secrets Operator or the Secrets Store CSI driver. Never commit plain secrets to Git; use Sealed Secrets or SOPS if they must live in a repository.

Mounted ConfigMaps and Secrets update in place (eventually), but environment variables only change when the pod restarts; many apps also need a reload or a rollout to pick up changes.

Key Points

• Base64 is not encryption.
• Encrypt etcd at rest; tight RBAC.
• External secret managers via operators/CSI.
• Env vars need a restart to change.