Goal

As an admin, I want a multi-tenant Argo CD control plane with low privileges which is able to reconcile Application CRs across the entire cluster, so that dev and ops teams can create Application CRs in various namespaces to control the sync behaviour for their respective cluster and application resources. The application CR in this scenario would define the privileges that the particular sync should have via controlling the service account privileges for the service account used for that specific application.

Acceptance Criteria

• A single Argo CD control plane exists across the cluster
• Argo CD control plane can reconcile Application CRs in any namespace
• Applications CRs can have varying access privileges to the cluster based on their service accounts
• AppProject CRs can define default access privileges for their Applications
• Argo CD dashboard displays Applications from the namespaces that user has access to

-------------------------------------

Scenario

As a user with access to specific OpenShift namespaces on a cluster ( Example, the dev- ,  code- and stage- namespaces on the dev sandbox), I would like to use GitOps to have kubernetes manifests sync'd to one or more namespaces I already have access to.

Background

ArgoCD is modeled around the constraint that Application CRs need to reside in the ArgoCD control plane only. Therefore, either an ArgoCD admin needs to create an Application CR or a user may do so by logging into the ArgoCD UI. 
 
Problem statement

The user needs to login to two Consoles ( openshift console, ArgoCD console ) to be able to 'tell' ArgoCD that something needs to be "sync'd", after the user has been provided access to the ArgoCD console implicitly or explicitly.

Acceptance Criteria

An ideal experience should be :

• The user logs into OpenShift Console, Or logs in to the cluster using the oc / kubectl CLI.
• The user, in the context of her own namespace creates an Application CR ( or an equivalent of the same ) referencing the Git Repo & credentials(optionally).
• A GitOps Engine ( an abstract concept as of now ) should "sync" manifests from Git.

All this should be possible without any intervention from the Argo CD Admin and should factor in the permissions the user has already been provided by the cluster-admin.

Long term

The topology view should reflect an out-of-sync application.

Upstream

https://github.com/argoproj/argo-cd/issues/3474