mirror of
https://github.com/kubernetes-sigs/kustomize.git
synced 2026-05-17 18:25:26 +00:00
a7df00c07a
[doc]: https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher Per this Go modules [doc] a repo or branch that's already tagged v2 or higher should increment the major version (e.g. go to v3) when releasing their first Go module-based packages. At the moment, the kustomize repo has these top level packages in the sigs.k8s.io/kustomize module: - `cmd` - holds main program for kustomize Conceivably someone can depend on this package for integration tests. - `internal` - intentionally unreleased subpackages - `k8sdeps` - an adapter wrapping k8s dependencies This exists only for use in pre-Go-modules kustomize-into-kubectl integration and won't live much longer (as everything involved is switching to Go modules). - `pkg` - kustomize packages for export This should shrink in later versions, since the surface area is too large, containing sub-packages that should be in 'internal'. - `plugin` - holds main programs for plugins This PR changes the top level go.mod file from ``` module sigs.k8s.io/kustomize ``` to ``` module sigs.k8s.io/kustomize/v3 ``` and adjusts all import statements to reflect the change.
1.0 KiB
1.0 KiB
FAQ
security: file 'foo' is not in or below 'bar'
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 refering to this directory as a
base from any kustomization that
wants to use it. This encourages modularity and
relocatability.
To disable this, use v3, and the load_restrictor flag:
kustomize build --load_restrictor none $target