Kustomize --load-restrictor and Security Errors
The --load-restrictor flag decides whether kustomize build can reference files outside its own directory tree.
By default Kustomize refuses to read files above its directory, a safety boundary. When a shared file legitimately lives elsewhere, you relax the restrictor, carefully.
What it does
kustomize build enforces a load restriction so a kustomization cannot reach arbitrary files on disk. The default, LoadRestrictionsRootOnly, forbids paths that escape the directory. LoadRestrictionsNone disables the check entirely, allowing absolute paths or ../ references outside the tree.
Common usage
# default: files must be in or below the directory
kustomize build overlays/prod
# allow files outside the directory (use sparingly)
kustomize build --load-restrictor LoadRestrictionsNone overlays/prodModes
| Mode | What it does |
|---|---|
| LoadRestrictionsRootOnly | Default: only files in or below the directory |
| LoadRestrictionsNone | Allow files anywhere, including outside the tree |
In CI
Prefer keeping files inside the kustomization tree (vendor or symlink shared config in) over loosening the restrictor, since LoadRestrictionsNone weakens the safety boundary. If you must relax it, scope it to the one build that needs it, and note that kubectl apply -k may not forward this flag, so render with standalone kustomize.
Common errors in CI
"security; file \"/path/x.yaml\" is not in or below \"/path/overlay\"" is the load restrictor blocking a path that escapes the directory; move the file inside or pass --load-restrictor LoadRestrictionsNone. The same error hits a secretGenerator or configMapGenerator files: entry pointing above the directory. Absolute paths trigger it even when the file exists.
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