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).
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).