You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, all file paths mentioned in a kustomization file must be defined relative to the location of the kustomization file.
This allows (e.g.) the following fishing attack. Someone writes a kustomization with a configmap generator that reads data from ../../../etc/passwd, and sends it to a victim, hopes the victim performs the kustomization in the correct working directory, and hopes to subsequently look at the cluster to see the data.
To prevent this, the following restriction is added:
All files paths mentioned in a kustomization file (resources, patches, config data) must refer to files in or below ., the location of the kustomization file.
Bases are not subject to this, and may be specified as living in sibling directories (or in remote URLs). A base can be viewed as an “import”, and its data files are subject to the same restriction but relative to that base.
Symlinks will be purged (e.g. via filepath.EvalSymlinks).
The text was updated successfully, but these errors were encountered:
This compulsory security feature is ridiculous @monopole
This avoids us using a genuine use case of template files outside of project files. You should have made it optional.
Currently, all file paths mentioned in a kustomization file must be defined relative to the location of the kustomization file.
This allows (e.g.) the following fishing attack. Someone writes a kustomization with a configmap generator that reads data from
../../../etc/passwd
, and sends it to a victim, hopes the victim performs the kustomization in the correct working directory, and hopes to subsequently look at the cluster to see the data.To prevent this, the following restriction is added:
All files paths mentioned in a kustomization file (resources, patches, config data) must refer to files in or below
.
, the location of the kustomization file.Bases are not subject to this, and may be specified as living in sibling directories (or in remote URLs). A base can be viewed as an “import”, and its data files are subject to the same restriction but relative to that base.
Symlinks will be purged (e.g. via
filepath.EvalSymlinks
).The text was updated successfully, but these errors were encountered: