kustomize: "Load from path ../ failed: security, file '...' is not in or below '...'

@hach-que The files in secretGenerators need to be relative paths in the kustomization directory or subdirectory. ../admin.yaml goes outside the kustomization directory. This is blocked in Kustomize 2.0.0.

@Liujingfang1 2.0.0 blocks relative paths everywhere as far as I can tell.

The issue is that kustomization.yaml is hard-coded, so how can I have two different kustomization targets when they need to draw on the contents of the Git repository? I can’t use relative parent paths anymore.

Imagine I have a directory structure like this (right now):

- dev
  - some_dev_specific_file.yaml
  - kustomization.yaml
- prod
  - some_prod_specific_file.yaml
  - kustomization.yaml
- some_files_used_by_both.yaml

With relative paths blocked, your proposal is now to put the kustomization.yaml file in the parent directory, like this:

- dev
  - some_dev_specific_file.yaml
- prod
  - some_prod_specific_file.yaml
- some_files_used_by_both.yaml
- kustomization.yaml (prod)
- kustomization.yaml (dev????? filename clash!)

Except that doesn’t work because you can’t have two files both named kustomization.yaml in the top level directory. There doesn’t appear to be any way to override the path or name of the kustomization.yaml file either when invoking kustomize.

Could you elaborate what was the motivation for blocking paths that are above given kustomization.yaml?

This is really annoying.

I had to go from

• base
  • file1.yaml
  • file2.yaml
  • file3.yaml
• dev
  • some_dev_specific_file.yaml
  • kustomization.yaml
• prod
  • some_prod_specific_file.yaml
  • kustomization.yaml

to

• base1
  • file1.yaml
  • kustomization.yaml
• base2
  • file2.yaml
  • kustomization.yaml
• base3
  • file3.yaml
  • kustomization.yaml
• dev
  • some_dev_specific_file.yaml
  • kustomization.yaml
• prod
  • some_prod_specific_file.yaml
  • kustomization.yaml

What I really want:

• base
  • file1.yaml
  • file2.yaml
  • file3.yaml
• dev-kustomization.yaml
• prod-kustomization.yaml

cannot share patches anymore 😢

edit: it works with --load_restrictor flag, but somehow the flag doesn’t work when using kubectl kustomize

I cannot understand this Kustomize team. (I’m sorry). So, everyone is complaining and explain that the relative-path block is very counterintuitive and the team just comes passing by casually, saying “NO” with little useful explanation? Huh…?

You can put the files used by both to base and include that base in both dev and prod.

I believe it is not possible to reuse common patches in this way?

@flickerfly the following works for v4.0.5 kustomize build --load-restrictor LoadRestrictionsNone

My use case is I have a few secrets in a shared encrypted keybase git repo used by applications not only run in kubernetes (mobile, desktop and various IOT apps) and I’d rather not have multiple copies or a makefile to shuffle files around before kustomize is run.

secrets/
    ...
platform/
  ios/
    ...
  android/
    ...
  k8s/
    base/
    next/
    production/

shared by using bases

Ok, but secretGenerator it is not resource, it is part of kustomization.yaml. It seems that kubectl create secret generic tls --from-file=./certs/tls.cert --from-file=./certs/tls.key is the only solution now 😦 (security doesn’t matter — it is used for local, since no doubt for production secrets created in another way).

Kustomize tries to protect developers from mistakes, it is great, but as workaround for such bugs shell script is used, that’s even worse 😦

As workaround, just add hard links (as symbolic links are also forbidden) 😦

# https://github.com/kubernetes-sigs/kustomize/issues/766
ln -f certs/tls.cert k8s/overlays/single-node/tls.cert
ln -f certs/tls.key k8s/overlays/single-node/tls.key

Resources should be shared by using bases - they can be located anywhere.

This is literally false. They cannot be located anywhere, which is the fundamental reason why users are complaining.

Two poorly designed features (probably not so poor when individually used) have broken the idea of using Kustomize to customise configuration: 1) an inaccurate recursion detection - only checks for whether a folder is accessible by a yaml and not if it is actually linked, and 2) requiring all files to be under or on the same level of a yaml

This functionality is most likely breaking security by having users change their directory structures to have entire projects under one folder which is inside a repository.

@hach-que You can put the files used by both to base and include that base in both dev and prod.

- base
   - some_files_used_by_both.yaml
   - kustomization.yaml
- dev
  - some_dev_specific_file.yaml
  - kustomization.yaml
- prod
  - some_prod_specific_file.yaml
  - kustomization.yaml

@mohnishkodnani I’m not sure I understand your problem. The base default has resources rbac and managers, but the overlay doesn’t work. Is that the problem you mean?

@Liujingfang1 I ran into the same issue after upgrading to kustomize 2.x. I was able to fix the problem by following your tip! To summarize the change I needed to make:

I have the following folder structure:

$ tree -d
.
├── base
└── overlays
    ├── staging
    └── production

To fix the problem:

1. I added file base/kustomization.yaml with:

resources:
- my-service.yaml

1. Updated overlays/staging/kustomization.yaml and overlays/production/kustomization.yaml to replace:

resources:
- ../../base/my-service.yaml
-patches:
...

… with …

bases:
- ../../base/
patchesStrategicMerge:
...

@swapnild2111 that is for version 3. In version 4 it is --load-restrictor. See https://github.com/kubernetes-sigs/kustomize/issues/3746

@flickerfly https://github.com/kubernetes-sigs/kustomize/issues/3746 I guess it is hyphenated now --load-restrictor, the documentation needs to be updated