Kustomize secretGenerator

secretGenerator creates Secrets from literals, files, or env files, base64-encoding the values and appending a content hash.

secretGenerator mirrors configMapGenerator but produces Secrets. Kustomize base64-encodes the values for you and hashes the name so updates roll out.

What it does

secretGenerator builds a Secret from literals, files, or env files. You supply plaintext; Kustomize base64-encodes it into the data field. It appends a content hash to the name (like configMapGenerator) and supports a type field for typed Secrets such as kubernetes.io/tls.

Common usage

kustomization.yaml

secretGenerator:
  - name: db-credentials
    literals:
      - username=app
      - password=s3cr3t
  - name: tls-cert
    type: kubernetes.io/tls
    files:
      - tls.crt
      - tls.key

Fields

Field	What it does
name	Base name of the Secret
literals	KEY=value pairs (values are base64-encoded for you)
files	Files whose contents become data entries
envs	Env file lines become data keys
type	Secret type, e.g. Opaque or kubernetes.io/tls
options.disableNameSuffixHash	Disable the content hash suffix

In CI

Never commit real secret values to the kustomization. In CI, pass secrets via env files written from the runner secret store, or use --load-restrictor handling for files outside the directory. Note the encoded values still land in the rendered manifest, so do not print kustomize build output to public logs.

Common errors in CI

A double-encoded Secret (garbage after decode) means the value was already base64 before Kustomize encoded it again; supply plaintext. For kubernetes.io/tls, the keys must be exactly tls.crt and tls.key or apply fails with "Secret ... type ... must contain tls.crt and tls.key". "security; file ... is not in or below the current directory" is the load restrictor blocking a files path; see the load restrictor reference.