ConfigMaps and Secrets

Keep settings in ConfigMaps and passwords in Secrets, pass them to a container as environment variables or files, and know when a change reaches a running Pod.

Your app needs settings: a mode, a color, a database password. You should not build them into the image, because then every change needs a new image. Kubernetes keeps them in two objects instead:

• A ConfigMap holds plain settings, such as APP_MODE=production.
• A Secret holds sensitive values, such as the password of your Django app's database.

Both are a list of keys with values. A container gets them in one of two ways: as environment variables, or as files in a folder.

Exam tasks here are short and very literal: a named object with named keys, used in a set way by a set container. The grader reads the object, then the Pod spec. It often runs env or cat inside the container too. Every detail in the task can be checked, so read it twice.

Create them with one command

Each source has its own flag, and the same flags work for ConfigMaps and Secrets.

# ConfigMaps
kubectl -n wl-config create configmap app-config --from-literal=APP_MODE=production --from-literal=APP_COLOR=blue
kubectl -n wl-config create configmap nginx-conf --from-file=default.conf=./site.conf   # key=path sets the key name
kubectl -n wl-config create configmap app-env --from-env-file=./app.env                  # one key per KEY=VALUE line
kubectl -n wl-config create configmap scripts --from-file=./scripts/                      # one key per file in the directory

# Secrets: same flags, plus a type
kubectl -n wl-config create secret generic db --from-literal=username=app --from-literal=password='s3cr3t!'

# Look before you mount
kubectl -n wl-config describe configmap app-config
kubectl -n wl-config get secret db -o yaml

Mixing up the last two is the most common reason a file or a variable comes out wrong. Take a Django app's .env file. --from-env-file=.env gives you DEBUG, SECRET_KEY and so on as separate keys. --from-file=.env gives you one key, .env, holding the whole file.

Secrets also have a type. For your own apps it is Opaque, which kubectl create secret generic makes. Other types each have one set job, and each is taught where it is used. TLS certificates are in Ingress, registry logins in Application failures, and service account tokens in RBAC.

base64 is an encoding, not protection

Secret values are stored in base64. That is an encoding, not encryption: anyone can turn it back into the original text with one command.

kubectl -n wl-config get secret db -o jsonpath='{.data.password}' | base64 -d; echo
echo -n 's3cr3t!' | base64        # -n matters: without it the trailing newline is encoded too
kubectl -n wl-config create secret generic db2 --from-literal=password='s3cr3t!' --dry-run=client -o yaml

• In a Secret's YAML, data takes base64 values.
• stringData takes plain text. The API server encodes it when it saves the Secret, and never shows stringData back to you.

Secrets are not encrypted by default. Anyone allowed to create Pods in a namespace can read every Secret there, just by mounting it. So the real protection is RBAC: who may read Secrets, and who may create Pods.

As environment variables

There are two ways to turn keys into environment variables:

• env with valueFrom: one key, and you choose the variable's name.
• envFrom: every key in the object, each as a variable with the key's name.

apiVersion: v1
kind: Pod
metadata:
  name: env-demo
  namespace: wl-config
spec:
  containers:
    - name: app
      image: busybox:1.36
      command: ["sleep", "3600"]
      env:
        - name: MODE                  # one key, under a new name
          valueFrom:
            configMapKeyRef:
              name: app-config
              key: APP_MODE
        - name: DB_PASS
          valueFrom:
            secretKeyRef:
              name: db
              key: password
      envFrom:                        # every key becomes a variable
        - configMapRef:
            name: app-config
        - prefix: DB_                 # username becomes DB_username
          secretRef:
            name: db

• If the ConfigMap, the Secret or the key does not exist, the container does not start. The Pod shows CreateContainerConfigError, and kubectl describe pod names the missing piece.
• Add optional: true to a reference only when the task allows the value to be missing.
• If env and envFrom set the same name, the one under env wins.

As files

A ConfigMap or Secret can also be a volume. Each key becomes a file, and the value becomes the file's contents. For example, a ConfigMap key default.conf becomes a file default.conf that nginx reads as its config.

    spec:
      containers:
        - name: nginx
          image: nginx:1.27
          volumeMounts:
            - name: conf                 # one file dropped into an existing directory
              mountPath: /etc/nginx/conf.d/default.conf
              subPath: default.conf
            - name: creds                # the whole Secret as a directory of files
              mountPath: /etc/creds
              readOnly: true
      volumes:
        - name: conf
          configMap:
            name: nginx-conf             # configMap uses "name" ...
            items:                       # only these keys, under these file names
              - key: default.conf
                path: default.conf
        - name: creds
          secret:
            secretName: db               # ... secret uses "secretName"
            defaultMode: 0400            # octal in YAML; the API stores it as 256

Watch out: a volume mounted on a folder hides whatever the image had in that folder. That is fine for an empty folder such as /etc/creds. On /etc/nginx it breaks nginx, because its main config file disappears. To add one file to a folder that already has content, use subPath. It has a cost, shown in the next table.

Which changes reach a running Pod

You edit a ConfigMap. Does the running app see the change? It depends on how the container gets it:

immutable: true on a ConfigMap or Secret is a one-way door. You cannot unset it; you can only delete the object. In return, the kubelet stops watching the object, which takes load off the API server in big clusters. And no one can change the config under a running app by accident.