Feature Request: Allow ArtifactGenerator to create ExternalArtifact in other namespaces

[matheuscscp]

A common use case Flux users have is a multi-tenant monorepo containing the YAML for all tenants. ArtifactGenerator does not support it today because it can only create ExternalArtifact in the same namespace as the ArtifactGenerator, which breaks multi-tenancy i.e. it requires cross-namespace source references in appliers, which in a multi-tenant setup are blocked.

For allowing ExternalArtifact to be created in a different namespace (i.e. not the namespace of the ArtifactGenerator producing it), we need to introduce two fields:

• .spec.artifacts[].namespace
• .spec.serviceAccountName

CRD XValidation via CEL expressions must block .namespace from being used when .serviceAccountName is not specified.

When .serviceAccountName is specified, source-watcher will impersonate the ServiceAccount for reconciling the ExternalArtifact objects. This means the ServiceAccount will require the necessary RBAC bindings. Because RBAC allows cross-namespace access for ServiceAccounts (since a ServiceAccount is really just a username at the end of the day and RBAC has no concept of namespaces for username), this will allow ExternalArtifact to be created in other namespaces, which in turn will allow cross-namespace source references to remain blocked for multi-tenant setups.

[stefanprodan]

One use-case for this is monorepo decoupling where the GitRepository and ArtifactGenerator sit in the flux-system namespace, while the generated ExternalArtifact objects should target tenant namespaces.

If we allow cross-namespace under impersonation, then cluster admins can use the same ResourceSet to generate the tenant namespaces + RBAC + kustomizations and also include an ArtifactGenerator that splits the monorepo into artifacts per tenant namespace.

[matheuscscp]

CRD XValidation via CEL expressions must block .namespace from being used when .serviceAccountName is not specified.

Actually, that's not how ResourceSet behaves.

A major use case we are planning to support is generating Flux Kustomizations dynamically with ArtifactGenerator.spec.pathPattern using ResourceSet. ResourceSet generates the appliers i.e. the Flux Kustomizations in any target namespace. Like a Flux Kustomization, Flux Operator ResourceSet inherits the controller RBAC, which in both cases is normally cluster-admin, which allows them to create things in any namespace. Multi-tenancy lockdown forces a .spec.serviceAccountName in both cases, which is how users can define what namespaces the Kustomization / ResourceSet can touch.

ArtifactGenerator should be no different. It should be allowed to create ExternalArtifact in any namespace if .spec.serviceAccountName is not specified and multi-tenancy lockdown is not enabled.