ConfigMap & Secret generators

Generate config with hashes.

Intermediate12 min · lesson 3 of 12

Kustomize can generate ConfigMaps and Secrets from files, literals, or env files, rather than you hand-writing them. The generators read the source data and emit a ConfigMap/Secret resource — and, by default, append a content hash to its name. That hash is the clever part: when the data changes, the name changes, which forces every workload referencing it to roll, so a config change triggers a rolling update automatically instead of silently leaving old pods with stale config.

HASH SUFFIX TRIGGERS A ROLLOUT

1Edit config data

literals / files / env in the generator

2Generator emits object

appends content hash: app-config-7h9k2t4b8m

3References rewritten

workloads repointed to the hashed name

4Pod spec changes

Deployment now names the new object

5Rolling update

K8s rolls pods — no stale config left

A data change yields a new hashed name, so the pod spec changes and Kubernetes rolls automatically.

kustomization.yaml

configMapGenerator:
  - name: app-config
    literals:
      - LOG_LEVEL=info
    files:
      - app.properties
 
secretGenerator:
  - name: db-creds
    envs:
      - db.env          # KEY=VALUE lines (keep this file out of Git if real!)

terminal

$ kustomize build .
kind: ConfigMap
metadata:
  name: app-config-7h9k2t4b8m   # <- content hash appended
# references to "app-config" are rewritten to the hashed name automatically

The hash suffix and rollouts

Kustomize rewrites references to the generated object (a Deployment mounting app-config) to point at the hashed name, so everything stays consistent. Because a data change yields a new hashed name, the Deployment’s pod spec changes, and Kubernetes performs a rolling update — solving the classic “I changed the ConfigMap but the pods still have the old value” problem without any manual restart. You can disable the suffix with a generator option if you truly need a stable name.

secretGenerator source data is still plaintext

A secretGenerator only base64-encodes the values into a Secret — it does not encrypt anything, and the source (literals in kustomization.yaml, or a db.env file) sits in your repo in plaintext if you commit it. Never commit real secret sources; use SOPS-encrypted files or an external secrets operator (the secrets lesson covers this) and keep secret material out of Git entirely.

kustomization.yaml & resourcesBuild & apply