<p>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:</p>
<pre><code>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..
</code></pre>
<p>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 &quot;
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'
&quot;</p>
<p>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.</p>

<p>You are seeing this error because it is there to protect users from phishing attack. Check out <a href="https://github.com/kubernetes-sigs/kustomize/issues/693" rel="nofollow noreferrer">this kustomize issue</a>.</p>
<p>From kustomize faq: <a href="https://kubectl.docs.kubernetes.io/faq/kustomize/#security-file-foo-is-not-in-or-below-bar" rel="nofollow noreferrer">security: file ‘foo’ is not in or below ‘bar</a>:</p>
<blockquote>
<p>v2.0 added a security check that prevents kustomizations from reading files outside their own directory root.</p>
<p>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 <a href="https://github.com/kubernetes-sigs/kustomize/issues/693" rel="nofollow noreferrer">#693</a>, <a href="https://github.com/kubernetes-sigs/kustomize/pull/700" rel="nofollow noreferrer">#700</a>, <a href="https://github.com/kubernetes-sigs/kustomize/pull/995" rel="nofollow noreferrer">#995</a> and <a href="https://github.com/kubernetes-sigs/kustomize/pull/998" rel="nofollow noreferrer">#998</a>).</p>
<p>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.</p>
<p>To disable this, use v3, and the load_restrictor flag:</p>
<pre><code>kustomize build --load_restrictor none $target
</code></pre>
</blockquote>
