K8s — ConfigMap vs Secret

InfrastructureMidkubernetes

The Question

What is the difference between a ConfigMap and a Secret in K8s?

What a Strong Answer Covers

• Secret = base64 not encrypted
• both mounting methods.

Senior-Level Answer

ConfigMaps and Secrets both decouple configuration from container images, but they differ in their intended sensitivity, storage handling, and access controls.

A **ConfigMap** stores arbitrary non-sensitive key-value pairs or entire config files — things like feature flags, log levels, or application properties. The data is stored as plain UTF-8 text in etcd. There is no additional encoding; what you put in is what you read out. ConfigMaps can be consumed as environment variables, command-line arguments, or files mounted into a pod via a projected volume.

A **Secret** is designed for sensitive data: passwords, TLS certificates, API tokens, and SSH keys. By default, Secret values are base64-encoded in the Kubernetes API — this is *encoding*, not *encryption*. The values are trivially reversible with `base64 -d`. The real security comes from layering additional controls: enabling **encryption at rest** in the API server (`EncryptionConfiguration` with an AES-GCM or KMS provider), tightening RBAC so only the pods and service accounts that need a Secret can `get` it, and using external secret managers (Vault, AWS Secrets Manager) via operators like External Secrets Operator.

Kubernetes applies some extra protections to Secrets by default: they are stored in a `tmpfs` (memory-backed) volume on the node rather than written to disk, and they are only sent to nodes that have a pod requesting them. However, anyone with `kubectl get secret` permission on the namespace can read all Secrets there, so RBAC hygiene is critical.

In practice, the injection patterns are identical: `envFrom`, `env.valueFrom.secretKeyRef`, or a `volume` mount. For Secrets in volumes, Kubernetes can also update the mounted file automatically when the Secret changes without restarting the pod, but environment variable injection requires a pod restart to pick up changes — an important operational difference for both resource types.

The key interview point is: base64 is not security. Treat Secrets as a namespace-level access-control primitive, not an encryption primitive, and back them with real encryption and least-privilege RBAC.

Key Differences

What Separates a 2/3 from a 3/3

Common Mistakes

• Claiming Secrets are encrypted by default — base64 is encoding, not encryption.
• Not mentioning that RBAC is the primary access-control mechanism for Secrets.
• Overlooking that environment variable injection does not auto-update; a pod restart is required.
• Treating ConfigMaps and Secrets as entirely different systems rather than the same API with different sensitivity conventions.

Follow-Up Questions

• How would you enable encryption at rest for Secrets in a self-managed cluster? — Describe EncryptionConfiguration manifest referencing an AES-GCM provider or a KMS plugin, applied to the API server and requiring re-encryption of existing Secrets.
• What is External Secrets Operator and why would you use it over native Secrets? — It syncs secrets from Vault/AWS/GCP into Kubernetes Secrets, keeping the source of truth outside the cluster and enabling rotation without touching manifests.
• What happens when a mounted Secret changes — does the pod need to restart? — Volume mounts are updated automatically by kubelet within the sync period. Env var injections are not — that requires a pod restart.
• How would you audit which pods have access to a specific Secret? — Use RBAC tooling (kubectl auth can-i --list, or tools like rbac-lookup) to enumerate ServiceAccounts and RoleBindings that grant get/list on the Secret.

Related Questions

• K8s — Pod vs Deployment
• K8s — Liveness vs Readiness
• Helm Chart
• Docker — Container vs VM
• CI/CD Pipeline