Day 53: Namespaces, ConfigMaps, Secrets
Organizing and configuring a cluster
Namespaces partition a cluster into virtual clusters — scoping names (two Deployments named "api" can coexist in different namespaces), and acting as a boundary for RBAC and resource quotas (Phase 11).
ConfigMaps hold non-sensitive configuration (feature flags, URLs) as key-value data, injectable into Pods as environment variables or mounted files — decoupling configuration from the container image so you don't rebuild an image just to change a setting.
Secrets hold sensitive data (passwords, API keys) with the same interface as ConfigMaps, but base64-encoded by default — a critical distinction covered fully in Phase 11: base64 is encoding, not encryption. Anyone with API read access to a Secret can trivially decode it; real protection requires RBAC restricting who can read Secrets at all, and often external secret management (Vault, External Secrets).
kubectl create configmap app-config --from-literal=LOG_LEVEL=info
kubectl create secret generic db-creds --from-literal=password=hunter2
# In a Pod spec:
# envFrom:
# - configMapRef: { name: app-config }
# - secretRef: { name: db-creds }Key terms
- Namespace
- A virtual cluster partition scoping names, RBAC, and quotas.
- ConfigMap
- Non-sensitive key-value configuration injectable into Pods.
- Secret
- Like a ConfigMap, but for sensitive data — base64-encoded by default, not encrypted.
A teammate says "our database password is safe because it's stored as a Kubernetes Secret." What's the flaw in that reasoning?
