Allow opting out of automatic generation of missing kustomization.yaml

[rycli]

The Flux CLI and Kustomize Controller currently default to generating a kustomization.yaml file in the Kustomization target paths, if no existing file is found. It also does so while recursively walking any directories that also match this condition.

This is documented, albeit briefly:

• https://fluxcd.io/flux/components/kustomize/ (mentions using kustomize, not entirely accurate)
• https://fluxcd.io/flux/components/kustomize/kustomizations/#path (mentions to the fallback behavior)
• https://fluxcd.io/flux/components/kustomize/kustomizations/#generating-a-kustomizationyaml-file (pratically, recommends against using this behavior)

I'd like to suggest introducing a feature flag to the Kustomize Controller to allow opting out of this behaviour. e.g., DisableMissingKustomizationGeneration. We'd also need to add a corresponding flag to the CLI.

This automatic generation feature, while convenient, does bring with it a couple concerns;

• It's a pretty significant departure from the default kustomize build or kubectl ... -k behavior (which is to fail). This naturally isn't the only difference (notably, enabling LoadRestrictionsNode by default), but is non-obvious. The equivalent behavior is only available in kustomize create, not kustomize build.
• Automatic imports may not [always] be desirable. Questions of repository hygiene aside, users may e.g., write manifests in "placeholder" locations, which risk being included unintentionally. The "obvious" solution is to add an empty/restricted kustomization.yaml file in there; however this requires (end-user) understanding of the exact "GitOps solution".
• There is a risk of breaking a lot of things when introducing/replacing a kustomization.yaml file, where one was previously generated.

For a bit of context on motivation; I'm running Flux in an environment with a majority of users who only occasionally interact with our FluxCD repositories (e.g., configuring applications, adding a new deployment, minor tweaks, etc). In-depth and "fresh" knowledge of Flux's behavior is therefore quite limited and lives with a few individuals. Knowledge management and automation/validation solutions help a lot, but I myself unintentionally added a kustomization.yaml file to our cluster directory... with disastrous results. Our Flux proficiency has since grown a fair bit ;-)

---

In terms of implementation, we're already tracking whether the kustomization.yaml files are being generated (see CreatedAction throughout https://github.com/fluxcd/pkg/blob/main/kustomize/kustomize_generator.go#L67), and feature flags & other details of how Kustomizations are resolved are already configurable. This would a relatively small implementation in code and be very testable behavior.

I'd be happy to look at implementing this, if it's something that would be agreed to :-)

[rycli]

@stefanprodan ; any thoughts on this?

[stefanprodan]

I'm not sure about this, giving yet another foot gun feels wrong to me. I wrote the auto-generation right after we starting Flux 2.0, it's there since forever.