ConfigMaps & Secrets
Separate configuration and sensitive data from container images.
You keep configuration out of images so the same image runs in any environment. Kubernetes provides two objects:
- ConfigMap — non-sensitive key/value config
- Secret — sensitive data (passwords, tokens, keys)
Both can be injected into Pods as environment variables or mounted files. Importantly, Kubernetes Secrets are only base64-encoded by default, not encrypted — you must enable encryption at rest and tight RBAC, or use an external secrets manager, to truly protect them.
apiVersion: v1
kind: ConfigMap
metadata: { name: app-config }
data:
LOG_LEVEL: "info"
---
apiVersion: v1
kind: Secret
metadata: { name: app-secret }
type: Opaque
stringData:
DB_PASSWORD: "s3cr3t" # stringData is auto base64-encoded# Inject into a Pod
envFrom:
- configMapRef: { name: app-config }
- secretRef: { name: app-secret }- Create a ConfigMap and inject it as environment variables.
- Create a Secret and mount it as a file in a Pod.
- Explain why a Kubernetes Secret is not truly secure by default.
- Name two ways to strengthen Secret protection.
Cheat Sheet▾
| Object | Use |
|---|---|
| ConfigMap | Non-sensitive config |
| Secret | Sensitive data (base64) |
envFrom | Inject all keys as env vars |
| volume mount | Inject as files |
| Encryption at rest | Protect Secrets in etcd |
| RBAC | Limit who can read Secrets |
| External store | Vault / cloud secret manager |
Common Interview Questions▾
What's the difference between a ConfigMap and a Secret?
Both inject configuration into Pods, but ConfigMaps hold non-sensitive data while Secrets hold sensitive data with base64 encoding and tighter access controls.
Are Kubernetes Secrets encrypted?
Not by default — they’re only base64-encoded. You must enable encryption at rest in etcd and restrict access via RBAC (or use an external secrets manager) to secure them.