Decoupling Configuration from Images
Baking configuration into a container image forces a rebuild for every environment change. Kubernetes ConfigMaps and Secrets let you inject configuration and sensitive values into Pods at runtime, either as environment variables or mounted files, keeping images environment-agnostic and reusable across dev, staging, and production.
Cricket analogy: Printing a team's specific opposition strategy directly onto the players' jerseys would mean reprinting jerseys for every different match; instead coaches hand out a separate briefing sheet (ConfigMap) before each game, keeping the jersey design reusable all season.
Creating and Structuring a ConfigMap
A ConfigMap stores non-sensitive key-value pairs or whole configuration files as plain text. It can be created from literals, files, or written directly as YAML.
Cricket analogy: A team's non-secret matchday info — ground name, toss time, weather forecast — is written on a simple public whiteboard (ConfigMap) that anyone can create by literally chalking values, pinning a printed sheet, or writing it out formally in the team manual.
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
data:
LOG_LEVEL: "info"
MAX_CONNECTIONS: "100"
app.properties: |
feature.newUI=true
cache.ttlSeconds=300apiVersion: v1
kind: Pod
metadata:
name: app
spec:
containers:
- name: app
image: myapp:1.0
envFrom:
- configMapRef:
name: app-config
env:
- name: LOG_LEVEL
valueFrom:
configMapKeyRef:
name: app-config
key: LOG_LEVELSecrets: Storing Sensitive Data
Secrets have the same API shape as ConfigMaps but are intended for sensitive values such as passwords, tokens, and TLS certificates. Values are stored base64-encoded, which is an encoding, not encryption -- anyone with API read access to the Secret can decode it. Enable encryption at rest and RBAC restrictions to actually protect Secret contents.
Cricket analogy: A locked equipment bag looks just like the regular kit bag (same API shape) but holds the team's confidential strategy notes; writing the notes in a simple substitution code (base64) isn't real security — anyone who finds the bag and knows the code can read it, so you still need a real padlock (encryption) and controlled bag-room access (RBAC).
apiVersion: v1
kind: Secret
metadata:
name: db-credentials
type: Opaque
data:
username: YWRtaW4=
password: czNjcjN0UGFzcw==Mounting a Secret as a Volume
Mounting Secrets as files (rather than environment variables) is generally preferred for sensitive data, since environment variables can leak into logs, crash dumps, or child process listings more easily than files with restricted permissions. Both ConfigMaps and Secrets can be mounted as volumes; when updated, mounted (non-subPath) files are eventually refreshed automatically by the kubelet, but environment variables are only set at Pod start and require a Pod restart to pick up changes.
Cricket analogy: Whispering the team's secret signal to a player quietly before the over (a file handed privately) is safer than shouting it across the field at the team huddle (env var), since a shouted signal can be overheard and stays fixed even if conditions change until the next huddle (restart).
apiVersion: v1
kind: Pod
metadata:
name: app
spec:
containers:
- name: app
image: myapp:1.0
volumeMounts:
- name: db-creds
mountPath: /etc/secrets/db
readOnly: true
volumes:
- name: db-creds
secret:
secretName: db-credentialsSecret data is base64-encoded, not encrypted. Never treat a Secret manifest as safe to commit to version control; use tools like Sealed Secrets, External Secrets Operator, or a vault integration for GitOps workflows.
- ConfigMaps hold non-sensitive config; Secrets hold sensitive data but only base64-encode it by default -- not encryption.
- Both can be consumed as environment variables (envFrom/valueFrom) or as mounted volumes.
- Volume-mounted ConfigMap/Secret files update automatically on change; environment variables do not, requiring a Pod restart.
- Prefer volume mounts over env vars for secrets to reduce accidental exposure via logs or process inspection.
- Enable encryption at rest and RBAC to genuinely secure Secret contents.
- subPath mounted files do NOT get automatically updated when the source ConfigMap/Secret changes.
Practice what you learned
1. What is the primary difference in intended use between a ConfigMap and a Secret?
2. How is data stored inside a Kubernetes Secret by default?
3. What happens to environment variables sourced from a ConfigMap when the ConfigMap is updated?
4. Why is mounting a Secret as a volume generally preferred over using it as an environment variable?
5. What is a key caveat when mounting a ConfigMap using subPath?
Was this page helpful?
You May Also Like
Environment Variables and Configuration
Learn how to configure containerized applications using environment variables, .env files, and Dockerfile defaults without rebuilding images.
Kubernetes Security Basics
Learn defensive Kubernetes security fundamentals: RBAC, NetworkPolicies, Pod security context, secrets handling, and image scanning.
Docker Security Basics
Defensive practices for hardening container images and runtime, including non-root users, minimal base images, vulnerability scanning, and dropped capabilities.
Namespaces and Resource Quotas
Understand how Kubernetes Namespaces provide multi-tenant isolation and how ResourceQuotas and LimitRanges enforce fair compute usage across teams.
Related Reading
Related Study Notes in DevOps
Browse all study notesNginx Study Notes
DevOps · 30 topics
DevOpsAnsible Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsCI/CD Tools & Pipelines Study Notes
YAML · 37 topics