SecretConfig Generator

In this tutorial, you’ll learn how to use Kustomize generators—both ConfigMap and Secret generators—to automatically trigger rollouts in Kubernetes when configuration changes. Kustomize appends a randomized suffix to generated resource names and updates all workload references at build time, ensuring seamless updates without manual kubectl rollout commands.

How Kustomize Generators Work

When you define a generator in Kustomize, it outputs a standard Kubernetes resource—either a ConfigMap or a Secret—with a unique suffix added to the name. This suffix guarantees that any change in generator inputs produces a new resource, prompting Kubernetes to detect updates and redeploy your workloads.

Example: Generating a ConfigMap named db-cred with a literal key-value pair:

apiVersion: v1
kind: ConfigMap
metadata:
  name: db-cred-jj26gh
data:
  password: "password1"

Kustomize ensures uniqueness by appending -jj26gh to the base name.

Your Deployment or Pod spec references the generator by its base name (db-cred), and Kustomize will rewrite it to include the full suffix:

env:
- name: DB_PASSWORD
  valueFrom:
    configMapKeyRef:
      name: db-cred
      key: password

At build time, this becomes:

env:
- name: DB_PASSWORD
  valueFrom:
    configMapKeyRef:
      name: db-cred-jj26gh
      key: password

Automatic Rollouts on Configuration Change

When you update the generator inputs—for instance, changing password1 to password2—Kustomize generates a new ConfigMap (e.g., db-cred-a477b) and updates your Deployment spec accordingly:

# Old ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
  name: db-cred-jj26gh
data:
  password: "password1"

# New ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
  name: db-cred-a477b
data:
  password: "password2"

# Before build
env:
- name: DB_PASSWORD
  valueFrom:
    configMapKeyRef:
      name: db-cred-jj26gh
      key: password

# After build
env:
- name: DB_PASSWORD
  valueFrom:
    configMapKeyRef:
      name: db-cred-a477b
      key: password

Since the ConfigMap name changes, Kubernetes treats the Deployment as updated and automatically initiates a rollout—no extra CLI steps required.

Defining a ConfigMap Generator

Add a configMapGenerator section to your kustomization.yaml. Specify the generator name and key-value pairs under literals:

configMapGenerator:
- name: db-cred
  literals:
    - password=password1

Running kustomize build produces:

apiVersion: v1
kind: ConfigMap
metadata:
  name: db-cred-jj26gh
data:
  password: "password1"

Using File Inputs for ConfigMaps

You can load entire files instead of literals. Kustomize uses the filename as the data key:

configMapGenerator:
- name: nginx-config
  files:
    - nginx.conf

Contents of nginx.conf:

server {
    listen 80;
    server_name example.com;
    location / {
    }
}

Generated resource:

apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-config-jj26gh
data:
  nginx.conf: |
    server {
        listen 80;
        server_name example.com;
        location / {
        }
    }

Defining a Secret Generator

Secrets follow the same pattern as ConfigMaps. Replace configMapGenerator with secretGenerator:

secretGenerator:
- name: db-cred
  literals:
    - password=password1

Generated Secret:

apiVersion: v1
kind: Secret
metadata:
  name: db-cred-dd6525th4g
type: Opaque
data:
  password: cGFzc3dvcmlQ

File-based secrets are also supported:

secretGenerator:
- name: nginx-secret
  files:
    - nginx-conf

Generator Types Overview

References

• Kubernetes ConfigMap Documentation
• Kubernetes Secret Documentation
• Kustomize Generators