Goal

When Argo CD is given access to a namespace through annotations, it assumes namespace-admin privileges and can modify objects that are not intended for dev teams to have access to e.g. NetworkPolicies. This is specially a problem for customers who provision namespaces for their dev teams and the dev team is not admin to the namespace. Installing an Argo CD instance in these namespace would give the dev team admin privileges to the namespace and indirectly elevates their assigned privileges. The operator should allow customers to provision Argo CD operands without interfering with assign privileges to the dev teams.

The limitation is preventing customers from using OpenShift GitOps and they opt for the community Argo CD operator.

Acceptance Criteria

• Cluster admin can provision Argo CD for tenants in a multi-tenant environment and give it access to manage namespace content through annotations without the Argo CD assuming namespace-admin privileges.
• Cluster admin can choose to maintain the existing behaviour and request Argo CD to be namespace-admin

Why does the customer need this?

If you label a namespace with argocd.argoproj.io/managed-by: argocd-instance RoleBindings are automatically created in the managed namespace: argocd- instance-argocd-application-controller, argocd-instance-argocd-dex-server, argocd-instance-argocd-redis-ha, argocd-instance-argocd-server. These Roles are high privileged and can delete all resources. In our context we don't want that NetworkPolicies could be deleted. So it would be nice if these Roles could be hardened.