mirror of
https://github.com/kubernetes-sigs/kustomize.git
synced 2026-05-18 12:42:19 +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.
31 lines
1.0 KiB
Markdown
31 lines
1.0 KiB
Markdown
# 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](https://github.com/kubernetes-sigs/kustomize/issues/693),
|
|
[#700](https://github.com/kubernetes-sigs/kustomize/pull/700),
|
|
[#995](https://github.com/kubernetes-sigs/kustomize/pull/995) and
|
|
[#998](https://github.com/kubernetes-sigs/kustomize/pull/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`](glossary.md#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
|
|
```
|