ConfigMaps and Secrets

Analogy categoryAnalogies

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.

yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  LOG_LEVEL: "info"
  MAX_CONNECTIONS: "100"
  app.properties: |
    feature.newUI=true
    cache.ttlSeconds=300

yaml

apiVersion: 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_LEVEL

Secrets: 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).

yaml

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).

yaml

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-credentials

Secret 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?

Services and Networking

StatefulSets and DaemonSets

Related Study Notes in DevOps

Browse all study notes

DevOps

Nginx Study Notes

DevOps · 30 topics

DevOps

Ansible Study Notes

DevOps · 30 topics

DevOps

Advanced Kubernetes Study Notes

Kubernetes · 30 topics

DevOps

Advanced Bash Scripting Study Notes

Bash · 30 topics

DevOps

Apache Kafka Study Notes

Kafka · 30 topics

DevOps

CI/CD Tools & Pipelines Study Notes

YAML · 37 topics

Topics covered

#YAML#DockerKubernetesStudyNotes#DevOps#ConfigMapsAndSecrets#ConfigMaps#Secrets#Decoupling#Configuration#StudyNotes#SkillVeris

Decoupling Configuration from Images

Creating and Structuring a ConfigMap

Secrets: Storing Sensitive Data

Mounting a Secret as a Volume

Practice what you learned

You May Also Like

Related Reading

Related Study Notes in DevOps

Topics covered