Common config across multiple environments and applications with Kustomize

12/4/2020

Is it possible to have a common config file (e.g. ConfigMap) which is shared across multiple environments and applications? I know it's simple to do it across with multiple environment overlays but how about a level above it for apps? If I have the following structure:

Base
    App1
    	Configmaps
        Kustomization.yaml
    Global
        Configmaps
Overlays
	Env1
		App1
			Configmaps
			Deployments
            Kustomization.yaml
		App2
			Configmaps
			Deployments
            Kustomization.yaml
	Env2.. (same as above)
		App1..
		App2..

Is it possible to some how a static set of common config values which is references across all applications? In the above structure I can only refer to resources within the same folder or below, if I try and refer to resource in a parent folder outside of the App level then you normally get an error such as " Error: AccumulateTarget: rawResources failed to read Resources: Load from path ../../configmaps/base-config.yaml failed: security; file '../../configmaps/base-config.yaml' is not in or below 'C:\Code\BUILD-ARTEFACTS\deployment-manifests\base\apps\app-ui' "

Is there anyway to share common configs at parent folder level not in the child folders? otherwise I end up repeating some of the settings across multiple apps which is not ideal.

-- Rubans
kubernetes
kustomize

1 Answer

12/7/2020

You are seeing this error because it is there to protect users from phishing attack. Check out this kustomize issue.

From kustomize 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 referring 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
-- Matt
Source: StackOverflow