Epic Goal

High level: Enable users to be able to deploy to their own namespaces, from their own Argo CD instance, instead of having to rely on cluster admins to label those namespaces for them.

The goal of this epic is to support the following scenario:

• A) A user (non-cluster-admin) has an Argo CD install on the cluster. They are admin on that Argo CD instance, but they are not on an admin on the cluster itself.
• B) The user own >1 other namespaces on the cluster. BUT, they do not own ALL namespaces, nor do they have the ability to write cluster-scoped resources.
• C) They wish to deploy to those other Namespaces mentioned in 'B)', from Argo CD mentioned in 'A)'.
• D) They would like to do C) without involving a cluster-admin.

The goal of this epic is thus to allow tenants (non-cluster-admins) to enable Argo CD to deploy to that same tenant's namespaces (via self service, without requiring help from cluster-admin).

Why is this important?

Currently, to deploy to a namespace on your cluster, you add the 'argocd.argoproj.io/managed-by: (argo cd namespace)' label to the Namespace (https://docs.openshift.com/gitops/1.10/argocd_instance/setting-up-argocd-instance.html). OpenShift GitOps then automatically adds that Namespace to the list of namespaces managed by Argo CD itself.

BUT: the permission to label Namespaces is usually reserved for a cluster-admin, so this doesn't work for self-serve.

With this feature, tenants that own an Argo CD instance, and own other namespaces, should be able to enable Argo CD management of the namespaces themselves.

Scenarios

1. Development teams are namespace admins in one or more namespaces they own, and would like to use all their namespaces to deploy application resources in specific namespaces. However, for this to work their namespaces must carry a specific label, and they don't have privileges to label their namespaces themselves even though they are admins in their own namespaces. They must rely on cluster admin interference every time. With this feature in place, they would be able to achieve this without admin interference.

Initial brainstorming of an API, `NamespaceManagement`

When this `NamespaceManagement` CR is created in Namespace `tenant-ui-team`, Argo CD will add that namespace to its list of managed namespaces. When the CR is deleted, the namespace is removed from Argo CD Secret's list of managed namespaces.

kind: NamespaceManagement
metadata: 
  name: ui-team-namespace
  namespace: tenant-ui-team # namespace of a hypothetical 'ui team'

spec: 
  managedBy: argo-cd-ns # namespace of argo cd instance, that will manage this namespace

status: 
  conditions: 
    - type: Reconciled # success!
      status: true 
    # or, in the error case: 
    - type: Reconciled
      status: false # fail, cluster admin needs to update ArgoCD CR, for example
      reason: ErrorOccurred
      message: ArgoCD resource does not allow management of this namespace.

Argo CD (cluster) admin would first need to configure '.spec.namespaceManagement' fields to enable this feature:

kind: ArgoCD
metadata: name: argo-cd
  namespace: argo-cd-ns

spec: # (...)
  namespaceManagement: # NEW FIELD, OPTIONAL
    - name: tenant-ui-team # allow a single namespace
      allowManagedBy: true
    - name: "tenant-*" # or, more useful, allow all tenants via wildcard
      allowManagedBy: true

Security Implications

This is what I have written, for inclusion in OpenShift GitOps docs for this feature. This talks through the security implications of enabling the feature:

• Before enabling this feature, you should be aware of the potential for privilege escalation.
• When enabling this feature, the following will become possible.
• If:
  • a user A has the ability to create/modify an 'ArgoCD' CR in some Namespace N1,
  • AND, that same user A has the ability to create a 'NamespaceManagement' CR in some Namespace N2
  • (where N1 and N2 are any two namespaces on the cluster)
• Then:
  • The Argo CD Operator will create Role/RoleBindings in N2 that (indirectly) grant user A a high degree of security privileges within the namespace.
  • As of this writing, these include, but are not limited to, reading all resources in the namespace, and writing/deleting deployments/secrets/configmaps/services/roles/rolebindings/serviceaccounts/subscriptions/persistentvolumeclaims, and so on.
    • The specific list of privileges granted can be found within '(argo cd instance name)-argocd-application-controller' Role within a Namespace that is labeled with the 'argocd.argoproj.io/managed-by: (argo cd instance)' label.

• Or, said another way:
  • When a user creates a 'NamespaceManagement' in a namespace, this is how the Argo CD Operator knows that that user should own that Namespace (or more specifically, to allow Argo CD to manage it, from an Argo CD instance that the user owns)
  • Thus, users should only be granted the ability to create/modify 'NamespaceManagement' CRs for namespaces they are expected to have full control over.

Thus, this feature should only be enabled if you are comfortable with assuming that users that are able to create NamespaceManagement within a namespace are likely to have full control over the resources in that Namespace.

Resources

See also these Slack threads:

• https://redhat-internal.slack.com/archives/C01RQH8KQ87/p1736426994014199
• https://redhat-internal.slack.com/archives/C01RQH8KQ87/p1738163971422889