kustomize-controller
kustomize-controller copied to clipboard
fluxcd
Make substituteFrom reference-able across namespace
Would like to use a single configmap preferably mounted in flux-system, which can be referenced to push some common substitution for kustomizations across namespace. Like environment.
Is there a supported way to define cluster-wide variables for replacement in a DRY way? Or a way to deploy a ConfigMap created with configMapGenerator to multiple namespaces?
Is there still interest in this? I'm looking at the same thing, would be nice to just be able to create a global configmap in a single namespace to hold common variables and point to it with a namespace field in substituteFrom
So we were able to get a workaround working, if we have a top level Kustomization in flux-system pull substituteFrom from a configmap in flux-system then we can have all sub components get the templating so we were able to workaround it
hi @ivelichkovich , I'm looking to do something similar, would be great and very much appreciated to know how you managed to do this if you're happy to share.
This is a fairly common use case especially for platform teams who want to supply configuration in a cluster that can be federated to all the tenants of the cluster.
This is why I created this mutating webhook which allows for the team operating the cluster to federate config to all the tenants. I'd be interested in hearing any feedback on how we could improve it, I know one thing it doesn't currently do is federate secrets but I'm still unsure on if that is actually a good idea because it could leak sensitive information, however, for configuration I think it's perfectly acceptable.
https://github.com/xUnholy/fluxcd-kustomize-mutating-webhook
I’m using Kyverno to sync tenant’s secretes from flux-system to all the namespaces belonging to a particular tenant. Example here https://github.com/controlplaneio-fluxcd/d1-fleet/blob/main/tenants/apps/policies/generate-secrets.yaml
I added the want fix label because Flux would never allow cross namespace access to secrets unless upstream Kubernetes allows it. When a Deployment would allow you to mount a Secret from another namespace, we’ll allow it too.