Because a patch shows only the edit, not the result. Kustomize merges patches into base resources, so a few lines in an overlay can change a securityContext, an image or a replica count in ways the patch file does not make obvious. Render with kubectl kustomize, then policy check and diff the final YAML.
How Kustomize builds the final manifests
Kubectl supports Kustomize directly. The Kubernetes documentation shows two commands:
kubectl kustomize DIRprints the resources found in a directory containing a kustomization file.kubectl apply -k DIRapplies them.
A kustomization lists resources, can generate ConfigMaps and Secrets, and applies patches using strategic merge or JSON 6902 through the patches field. Patches may be a file or an inline string and can target one or many resources. Generated ConfigMaps get a name suffix derived from content, which you can see in the rendered output.
Where review goes wrong
| What reviewers see | What can be hidden |
|---|---|
| A three line patch to the deployment | The merged result has a different securityContext than the base intended |
| A new overlay directory | A copy of the base with different image or limits |
| A generator entry | A ConfigMap or Secret with content pulled from a file |
| A patch targeting many resources | Changes applied to every matching object, not just the one you were thinking of |
Reviewers read what changed in the pull request. The output of the build is what runs in the cluster.
A review process that works
- Render in CI for every overlay:
kubectl kustomize overlays/prod > prod.yaml. - Run policy checks on the rendered file. No privileged containers, no hostPath, allowPrivilegeEscalation false, runAsNonRoot, image digests, resource limits.
- Diff against live with
kubectl diff -k overlays/prod. See using kubectl diff. - Compare overlays to each other. A diff between the staging and production render shows exactly where they differ, which is often where a security setting got dropped.
- Store the rendered output as a build artifact so what you checked is what you deploy.
Secrets and generators
Kustomize can generate Secrets from literals or files. If the source is a plaintext file in the repository, you have recreated the problem of secrets in version control. Reference an external secret store instead, and keep generators for non sensitive configuration.
Try it yourself
Click through it at your own pace, or open it full screen.
See how the gate evaluates the change set as a whole. Your Kustomize build output should be the thing that gate evaluates.
Quick check
What is the quickest way to see what an overlay produces?
Run kubectl kustomize on the overlay directory. It prints the final resources.
Should policy checks run on the base or the overlay?
On the rendered result of each overlay, because that is what gets applied.
Safeguard runs policies and gates on pull requests, so a failed rule can hold a merge, and its dependency and SBOM scanning covers the packages your infrastructure code pulls in. You can try a free scan at gold.safeguard.sh/scan.
Sources
- Declarative management of Kubernetes objects using Kustomize, Kubernetes documentation
- kubectl diff reference, Kubernetes documentation
Last reviewed: 19 October 2026.
