[RFC] External Artifact API

[stefanprodan]

This RFC proposes the introduction of a new API called ExternalArtifact that would allow 3rd party controllers to act as a source of truth for the cluster desired state. In effect, the ExternalArtifact API acts as an extension of the existing source.toolkit.fluxcd.io APIs that enables Flux kustomize-controller and helm-controller to consume artifacts from external source types that are not natively supported by source-controller.

[jakobmoellerdev]

Hey there 👋 Thanks for sharing this in Draft State, cool to see such a development!
(FYI @Skarlso @fabianburth who also worked on the proposal)

This looks very similar to https://github.com/openfluxcd / #5058 original proposal with the main difference being that you use the ExternalArtifact instead of any arbitrary SourceRef.

I am wondering how this would be different to having a CRD that pulls OCI artifacts and then referencing those...

Maybe its even worth thinking about standardizing ExternalArtifacts completely to OCI? I think we talked about this in the Flux community call when the original proposal of openflux was discussed.

The main drawback we mentioned back then still persists:
If we have an ExternalArtifact, Flux will always need to reference ExternalArtifact, and users will not be able to use their origin CRDs. In your Example release-controller would work on a GitHubRelease but the Kustomization still contains ExternalArtifact.

At this point, why not think about having release-controller directly download OCIArtifacts, expose a registry endpoint, and then use the already available Flux types?

This is ultimately what caused us to not follow up on the design.

If there are cases when working with an OCIRegistry is not desired, or unfeasible (e.g. working with SFTP and converting that to OCI Artifacts may be unfeasible / undesirable), then I still see value in this CRD even with the indirection in place!

Looking forward to see where this goes! 🎉

[stefanprodan]

If we have an ExternalArtifact, Flux will always need to reference ExternalArtifact, and users will not be able to use their origin CRDs.

@jakobmoellerdev an arbitrary sourceRef would imply opening up RBAC and the Flux CRD to unknown kinds, which would imply a v2 of Flux Kustomization and a v3 of HelmRelease. With ExternalArtifact the Flux RBAC does not changes, as Flux controllers already have all the permissions needed for the source.toolkit.fluxcd.io APIs and instead of dropping the allow list in the Flux CRDs we will just add another owned Kind to that which does not changes the security stance of Flux.

At this point, why not think about having release-controller directly download OCIArtifacts, expose a registry endpoint, and then use the already available Flux types?

Hosting an OCI registry inside the cluster and pushing content to it from a controller is way more challenging and involving than embedding a Go file server in a custom controller. Given that source-controller contains a storage implementation that can easily be copied in any other controller, the effort to expose artifacts to Flux is significant lower. If running a registry inside the cluster is feasible for you, then using OCIRepository is the right way to go, this RFC is for offering an alternative solution which IMO is easier to implement for 3rd party controllers.