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
secretGenerator:
- name: db-credentials
literals:
- username=app
- password=s3cr3t
- name: tls-cert
type: kubernetes.io/tls
files:
- tls.crt
- tls.keyFields
| 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.
Using this in CI
A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.
# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods
# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info
# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodes