Project configurations in any namespace

[OpenGuidou]

Summary

Some of the configuration shouldn't be centrally managed, as different user groups (linked to projects) may want to define them on their own.

Motivation

We should make the distinction between some central configuration, only accessible to the ArgoCD instance maintainers, and some configuration that can be distributed to the users. In a multi-tenant organization, each of those groups should be able to managed their part of the configuration. With the Application in any namespace feature, it's now possible to not open the in-cluster ArgoCD namespace to some of its users, and let them use their own namespace.

We should extend that to some configuration that would only affect their project, such as:

• Notifications (configmap and secret)
• ConfigManagementPlugin
• Plugin generators (configmap and secret)

It's implicitly requiring those elements to be able to be bound to a specific project.

I'm excluding here RBAC as it's already being discussed here: #8324

Edit: Notifications support is already implemented:

In order to enable this feature, the Argo CD administrator must reconfigure the argocd-notification-controller workloads to add --application-namespaces and --self-service-notification-enabled parameters to the container's startup command.
 --application-namespaces controls the list of namespaces that Argo CD applications are in. --self-service-notification-enabled turns on this feature.

Proposal

1. Enable the feature via the flag --application-namespaces in the application controller, applicationset controller and notifications controller.
2. Reuse the .spec.sourceNamespaces in the AppProject to allow to source configuration as well.
3. Read the configmaps (and linked secrets) in those namespaces using a dedicated label argocd.argoproj.io/cm-type= with different values according to their usage. Values could be notifications and plugin-generator
4. Read ConfigManagementPlugins directly in the target namespaces
5. Those configurations should only be accessible to the AppProject referencing this source namespace.

[andrii-korotkov-verkada]

Sounds good. How would we handle possible duplication of configurations across the namespaces, e.g. if there are different notifications secrets for sending data to multiple places, or same place but different role/permission?

[OpenGuidou]

I would propose to keep the global configuration where it stands, and then apply the project-level configuration as overrides. If conflicts occur, I would raise a warning in the resource sync status. WDYT ?

[andrii-korotkov-verkada]

That can work I think.