TLDR: This is blocked on either moving kubectl into its own repo, or changing its dependencies. ETA k8s ~1.20.
The adoption of go modules in the kubernetes/kubernetes repo broke the update process for kustomize. This is due to the kustomize libraries depending on the kubernetes apimachinery libraries, which are published out of the kubernetes staging directory.
2 pieces of work are underway which will allow kustomize to be updated in kubectl:
Once either of these issues is resolved we will then update kubectl with the latest kustomize version.
v2.0 added a security check that prevents kustomizations from reading files outside their own directory root.
This was meant to help protect the person inclined to download kustomization directories from the web and use them without inspection to control their production cluster (see #693, #700, #995 and #998)
Resources (including configmap and secret generators)
can still be shared via the recommended best practice
of placing them in a directory with their own
kustomization file, and referring to this directory as a
base from any kustomization that
wants to use it. This encourages modularity and
To disable this in v3, use the
kustomize build --load_restrictor none $target
To disable this in v4+, use the
kustomize build --load-restrictor LoadRestrictionsNone $target
Example: #1319, #1322, #1347 and etc.
The fields transformed by kustomize is configured explicitly in defaultconfig. The configuration itself can be customized by including
apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization configurations: - kustomizeconfig.yaml
The configuration directive allows customization of the following transformers:
commonAnnotations:  commonLabels:  nameprefix:  namespace:  varreference:  namereference:  images:  replicas: 
To persist the changes to default configuration, submit a PR like #1338, #1348 and etc.
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.