Dropped support for custom command(s) to generate manifests in flux v2

[cubbasa]

One of the biggest breaking change in flux v2 is to drop support for custom command(s) to generate manifests which limit usage of flux v2 and require some extra steps to generate plain yamls before they could be deployed with flux v2.
According to the docs: https://toolkit.fluxcd.io/faq/#are-there-any-breaking-changes
"Unfortunately we needed to drop the support for custom commands as running arbitrary shell scripts in-cluster poses serious security concerns." the reason of that are security issues.
My question is how it could be insecure or what exactly were arguments that way will lead to treat them as insecure? I could imagine that it could be as safe as build in commands (like kustomize or helm) with some extra security steps. First security measure is that custom binaries need to be manually added to flux image (like custom binary of template engine) so they need to be manged by someone who has full control over flux v2 deployment and access to cluster anyway and use path that was possible in flux v1 that require to be flux image extended. Second step for commands or custom binaries could be to declare them using CRD and only declared binary or command(s) could be used to generate manifests and only reference them as the whole and with that we could prevent any malicious kind of changes or ingestion.
I'm really open to any docs or links that could lead me to know what were issues to lead to this approach and I would like to address them because lack of custom command(s) is make almost impossible to migrate from flux v1 to flux v2 because they require add complexity (changes in CI pipelines, extra intermediate repositories) just to generate manifests that could be used by flux v2.

[squaremo]

For me, the difficulty with .flux.yaml is more that it introduces a slew of usability problems:

• it is hard to get the commands right, and hard to troubleshoot when they are not right (or suspected of not being right).
• the update automation doesn't work well with kustomize -- it keeps updates in a patch file off to the side, which you have to take into account if you want to examine what's being synced;
• if you want to use something other than kustomize, you have to build your own custom image, or copy executables over from an initContainer;
• generating manifests just before syncing means you don't get an opportunity to lint them, validate them, or verify they are what you expected.

It's plausible that the kinks could be hammered out, given time and effort -- there is nothing entirely insurmountable there. The last item is a matter of principle rather than execution, and is harder to discount.

Does the above explanation make it clearer why .flux.yaml is deprecated? I'm sorry this creates a dilemma for you.

We can help with advice on how to use other tooling to get YAMLs into shape and available to Flux; e.g., GitHub Actions. There's also (now) the ability to use an S3 bucket (or Minio) as a source for YAML files, which might save you figuring out how to fit them back into git. Lastly, Flux v1 still has a way to run, so we will have a good few months in which to sort these things out.