ConfigMaps and Secrets

What is it?#

Configuration that changes between environments must not live in the image, or you need a different image per environment and lose the "build once, promote the same artefact" property.

kubectl create configmap app-config --from-literal=LOG_LEVEL=debug
kubectl create secret generic db-creds --from-literal=password=s3cret

How to use it#

The three ways to consume them#

spec:
  containers:
    - name: app
      image: myapp:1.0

      # 1. ALL keys as environment variables
      envFrom:
        - configMapRef: { name: app-config }
        - secretRef:    { name: db-creds }

      # 2. ONE key, renamed — the form you want for secrets
      env:
        - name: DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: db-creds
              key: password

      # 3. As FILES in a volume
      volumeMounts:
        - name: config
          mountPath: /etc/app        # each key becomes a file
          readOnly: true

  volumes:
    - name: config
      configMap:
        name: app-config
        items:                        # optional: pick specific keys
          - key: app.yaml
            path: application.yaml

Which to choose#

Making a config change actually deploy#

Nothing restarts a pod when a ConfigMap changes — the pod spec did not change, so there is no new ReplicaSet and no rollout.

kubectl rollout restart deploy/web        # the quick fix

The durable fix is to make the config change visible to the Deployment:

spec:
  template:
    metadata:
      annotations:
        checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }}

Now editing the ConfigMap changes the annotation, which changes the pod template, which triggers a normal, observable, rollback-able rollout. Kustomize does the same with configMapGenerator name suffixes.

Making Secrets actually secret#

A Secret alone gives you very little. Four things are needed:

# Who can read Secrets in this namespace? Run this on your own cluster.
kubectl auth can-i get secrets --as=system:serviceaccount:prod:default -n prod
kubectl get rolebindings,clusterrolebindings -A -o wide | grep -i secret

What goes wrong#

Interview corner · الأسئلة اللي بتتسأل#

kubectl get secret db -o jsonpath='{.data.password}' | base64 -d

kubectl rollout restart deploy/web

Key takeaways#

• A Secret is base64, not encrypted. Security comes from RBAC, encryption at rest, and an external store — not from the object type.
• Environment variables never update. Only volume mounts do, and not with subPath.
• Nothing restarts a pod on a config change — use a checksum annotation, or rollout restart.
• subPath silently disables live updates, which is exactly the case where you expected them.
• Prefer files over env vars for secrets — env is visible to the whole process tree.
• Both are namespaced. Shared certs and registry credentials need replication.
• Immutable ConfigMaps turn config into versioned, revertible deploys.

Last updated 2026-09-13