ConfigMaps and Secrets¶

Overview¶

Mount ConfigMaps and Secrets into a Pod (env and volume) and use Downward API for pod metadata — without baking config into images.

ConfigMap = non-sensitive config. Secret = sensitive data (still base64 in etcd — enable encryption at rest and prefer external secret stores in production).

This is a core tutorial in Module 8 · Configuration of the REBASH Academy Kubernetes for Cloud & DevOps Engineers series — written for Cloud, DevOps, Platform, and SRE engineers.

Prerequisites¶

Persistent Volumes and Storage

Learning Objectives¶

By the end of this tutorial, you will be able to:

Create ConfigMap / Secret
Inject via envFrom and volume mounts
Use Downward API fields
State Secret limitations

Architecture¶

This topic’s control points and relationships are shown below.

Theory¶

What it is¶

ConfigMaps hold non-sensitive configuration (files, key/value settings). Secrets hold sensitive material (tokens, passwords, TLS keys). Both inject into Pods as environment variables or mounted files. The Downward API exposes Pod metadata (name, namespace, labels, resource values) without hard-coding. The goal is twelve-factor style config: images stay generic; environment-specific data lives in the cluster (or an external store).

Why it matters¶

Baking config into images forces rebuilds for every environment and leaks secrets into registries. Separating config enables the same artefact across dev/stage/prod. Understanding Secret limitations matters for CKS-level security: etcd contents, RBAC read access, and encryption at rest are operational concerns, not optional polish.

How it works (mental model)¶

Create ConfigMap/Secret objects (literals, files, or YAML).
Reference them from a Pod/Deployment via env, envFrom, or volumes + volumeMounts.
Kubelet materialises values into the container environment or filesystem.
Updates to ConfigMaps/Secrets mounted as volumes can appear as file changes (depending on projection); env vars typically need a Pod restart.
Downward API fieldRef / resourceFieldRef populate fields from the running Pod object.

Prefer external secret managers (cloud SM, Vault, ESO) for production credentials.

Key concepts / comparisons¶

Object	Use
ConfigMap	Non-sensitive config
Secret	Sensitive data (still base64 in API)
Downward API	Pod/cluster metadata injection

Injection	Pros	Cons
Environment variables	Simple	Restart to refresh; visible in process listings
Volume mounts	Good for files; can update	App must reload files

Common pitfalls¶

Believing Secrets are encrypted by default — they are base64-encoded, not ciphertext, unless encryption at rest is enabled.
Wide RBAC allowing get secrets cluster-wide.
Huge ConfigMaps (1 MiB object limits) or embedding binaries.
Committing Secret YAML with real credentials into Git.
Expecting env-injected values to hot-reload after ConfigMap edits.

Hands-on Lab¶

Create a workspace for this tutorial.

mkdir -p ~/rebash-k8s/module-08 && cd ~/rebash-k8s/module-08

Focus: Inject configuration and secrets into Pods without baking them into images

Step 1 – Create ConfigMap and Secret¶

kubectl create namespace rebash-lab
kubectl -n rebash-lab create configmap app-config --from-literal=APP_ENV=lab --from-literal=LOG_LEVEL=info
kubectl -n rebash-lab create secret generic app-secret --from-literal=DB_PASSWORD='s3cret-lab'
kubectl -n rebash-lab get configmap,secret

Step 2 – Mount them into a Pod and verify¶

cat > pod-config.yaml <<'EOF'
apiVersion: v1
kind: Pod
metadata:
  name: cfg-demo
  namespace: rebash-lab
spec:
  containers:
  - name: demo
    image: busybox:1.36
    command: ["sh", "-c", "env | grep -E 'APP_|DB_|LOG_'; sleep 3600"]
    envFrom:
    - configMapRef:
        name: app-config
    - secretRef:
        name: app-secret
EOF
kubectl apply -f pod-config.yaml
kubectl -n rebash-lab wait --for=condition=Ready pod/cfg-demo --timeout=60s
kubectl -n rebash-lab exec cfg-demo -- sh -c 'env | grep -E "APP_|DB_|LOG_"'

Final step – Cleanup note¶

kubectl delete namespace rebash-lab --ignore-not-found
# Workspace kept for notes; remove with: rm -rf "$(pwd)" when finished

Validation¶

Lab commands run under ~/rebash-k8s/module-08/
You can explain each Theory section in your own words
You used modern tooling where it applies to this topic
You can describe one production failure mode for this topic

Code Walkthrough¶

Production practice for ConfigMaps and Secrets always combines:

Inspect before you change (status, plan, logs, dry-run)
Prefer reversible, documented changes (Git, IaC, drop-ins, version pins)
Capture evidence (command output, pipeline logs) for handovers
Prefer current tools and APIs over legacy shortcuts
Least privilege — escalate credentials only when required

Keep runbooks short enough to follow under pressure. Automate checks; keep humans for judgement.

Security Considerations¶

Treat credentials and tokens for kubernetes as privileged — never commit them
Prefer short-lived auth (OIDC, roles, SSO) over long-lived keys
Validate blast radius before apply/deploy/delete operations
Restrict who can approve production changes
Collect audit logs; limit who can read sensitive traces

Common Mistakes¶

Believing Secrets are encrypted by default — they are base64-encoded, not ciphertext, unle

Validate assumptions against the Theory section and official docs before changing production.

Wide RBAC allowing get secrets cluster-wide.

Lab shortcuts (open security groups, admin roles, skip approvals) must not ship unchanged.

Changing production without a rollback path

Always know how to revert (previous artefact, prior release, state rollback, DNS failback).

Best Practices¶

Encode ConfigMaps and Secrets changes as code and review them in pull requests
Pin versions (images, modules, actions, provider plugins)
Separate environments with clear promotion gates
Alert on symptoms with runbooks attached
Destroy lab resources; tag everything with owner and expiry where possible

Troubleshooting¶

Symptom	Likely cause	Fix
Auth / permission denied	Wrong identity, policy, or scope	Check caller identity, roles, and least-privilege policies
Timeout / no route	Network, DNS, security group, or endpoint	Trace path, DNS, and allow-lists before retrying
Drift / unexpected plan	Manual change or wrong state/workspace	Reconcile desired vs actual; avoid click-ops on managed resources
Pipeline/job red	Flaky step, cache, or missing secret	Read failing step logs; bisect recent workflow/config changes
Cost spike	Idle load balancer, NAT, oversized compute	Inventory billable resources; stop/delete labs promptly

Summary¶

ConfigMaps and Secrets is essential for Cloud and DevOps engineers working with kubernetes. Practise the lab until the inspection and change path is muscle memory, then continue the track.

Interview Questions¶

What is the difference between a ConfigMap and a Secret in Kubernetes?
How can applications consume ConfigMap and Secret data at runtime?
What happens to running Pods when you update a ConfigMap that is mounted as a volume?
Why should Secrets not be treated as strong encryption at rest by default, and what controls improve their security?
When would you prefer environment variables versus volume mounts for configuration?

Sample answer — question 2

Applications can inject keys as environment variables, mount them as files via volumes, or use the Kubernetes API. Environment variables suit simple scalars; volume mounts suit files and live updates for many volume-mounted ConfigMaps.

Sample answer — question 4

etcd may store Secrets only base64-encoded unless encryption at rest is enabled. Improve security with encryption providers, least-privilege RBAC, external secret managers, short-lived credentials, and avoiding logging Secret values.

References¶

ConfigMaps · Secrets