What is the difference between a ConfigMap and a Secret in Kubernetes?
Learn the difference between Kubernetes ConfigMaps and Secrets: when to use each, base64 vs encryption, RBAC protection, and how Pods consume them.
Expected Interview Answer
A ConfigMap stores non-sensitive configuration data as plain key-value pairs, while a Secret stores sensitive data such as passwords, tokens, and keys with base64 encoding and tighter access controls.
Both decouple configuration from container images so the same image runs across environments, and both can be consumed as environment variables or mounted files. The key differences are intent and protection: Secrets are stored base64-encoded (not encrypted by default), can be encrypted at rest via an EncryptionConfiguration, are kept out of most logs, and are restricted with RBAC. ConfigMaps are meant for anything you would not mind seeing in plain text.
- Separates configuration from image builds
- Lets one image run in dev, staging and prod
- Secrets add RBAC and encryption-at-rest options
- Both mount as env vars or files
- Updates without rebuilding containers
AI Mentor Explanation
A ConfigMap is like the openly published match schedule and pitch report pinned in the dressing room — anyone can read venue, start time and format. A Secret is like the sealed team strategy and bowling plan the captain keeps locked away, shared only with players who need it. Both guide how the team plays, but one is public information and the other is guarded and access-controlled.
Step-by-Step Explanation
Step 1
Identify the data's sensitivity
Decide whether a value is safe in plain text (ConfigMap) or confidential like a password or token (Secret).
Step 2
Create the object
Use kubectl create configmap or kubectl create secret, or define them declaratively in YAML manifests.
Step 3
Reference it in the Pod
Consume values via envFrom/valueFrom for environment variables or a volume mount for files.
Step 4
Lock down Secrets
Apply RBAC to limit who can read Secrets and enable encryption at rest on etcd for real protection.
Step 5
Roll out changes
Update the object and restart or reload Pods so the new configuration takes effect.
What Interviewer Expects
- Clear statement that Secrets are for sensitive data
- Knowledge that Secret data is base64-encoded, not encrypted by default
- Awareness of encryption-at-rest and RBAC for Secrets
- Both can mount as env vars or files
- Understanding of decoupling config from images
Common Mistakes
- Claiming Secrets are encrypted out of the box
- Storing passwords in a ConfigMap
- Thinking base64 encoding provides security
- Forgetting to restrict Secret access with RBAC
- Committing Secret YAML with real values to version control
Best Answer (HR Friendly)
“A ConfigMap holds ordinary settings like a URL or a feature flag, while a Secret holds sensitive things like passwords and API keys with extra protection. Both let you change an app's configuration without rebuilding it, but Secrets are meant to be guarded more carefully.”
Code Example
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
data:
LOG_LEVEL: "info"
API_URL: "https://api.example.com"
---
apiVersion: v1
kind: Secret
metadata:
name: app-secret
type: Opaque
data:
# value is base64-encoded (echo -n 'p@ss' | base64)
DB_PASSWORD: cEBzcw==
---
apiVersion: v1
kind: Pod
metadata:
name: web
spec:
containers:
- name: web
image: nginx
envFrom:
- configMapRef:
name: app-config
- secretRef:
name: app-secretFollow-up Questions
- How do you encrypt Secrets at rest in Kubernetes?
- How can you inject a Secret as a mounted file instead of an env var?
- What is the risk of base64 encoding for Secrets?
- How does RBAC protect Secrets?
- How would you integrate an external secrets manager like Vault?
MCQ Practice
1. How is data stored in a Kubernetes Secret by default?
By default Secret values are base64-encoded, which is encoding not encryption; encryption at rest must be enabled separately.
2. Which object is appropriate for a non-sensitive log level setting?
Non-sensitive configuration like a log level belongs in a ConfigMap; Secrets are reserved for confidential data.
3. Which mechanism truly protects Secret contents in etcd?
Enabling encryption at rest with an EncryptionConfiguration encrypts Secret data in etcd; base64 alone offers no protection.
Flash Cards
ConfigMap vs Secret in one line? — ConfigMap holds non-sensitive config in plain text; Secret holds sensitive data with base64 encoding, RBAC and optional encryption at rest.
Is a Secret encrypted by default? — No. It is base64-encoded by default; you must enable encryption at rest for real protection.
How can both be consumed by a Pod? — As environment variables (envFrom/valueFrom) or as mounted files via volumes.
Why not put a password in a ConfigMap? — ConfigMaps have no additional access controls and are treated as plain text, exposing the credential.