Extend edit access to ArgoCD instances to cluster-admin role

[mamurak]

After deploying a validated pattern, e.g. Edge Anomaly Detection, I can view the ArgoCD Applications in the cluster and project ArgoCD instances, but I'm unable to manually trigger Sync. When attempting to manually trigger Sync, I receive the following error message:

Unable to deploy revision: permission denied: applications, sync, default/edge-anomaly-detection-hub, sub: CiRjMWFiNGZiNi1kMjkxLTQzNDgtODljNy1mYmI2Y2ViYjUxNWMSCW9wZW5zaGlmdA, iat: 2023-11-08T16:36:55Z

I'm logged in as a user with cluster-admin role, but tt seems the default RBAC configuration of ArgoCD allows only kubeadmin full access. Deploying the pattern as kubeadmin is not always feasible for regular pattern users, so I propose to extend the ArgoCD RBAC rules to grant any user associated with the cluster-admin role edit permissions.

[claudiol]

@mamurak Thanks for bringing this to our attention. We (@mbaldessari and myself) have replicated the issue using our clusters and here are some of our findings:

Default OpenShift Gitops RBAC ConfigMap
The cluster wide ArgoCD instance has the following default RBAC policy in the config map:

apiVersion: v1
data:
  policy.csv: |
    g, system:cluster-admins, role:admin
    g, cluster-admins, role:admin
  policy.default: role:readonly
  scopes: '[groups]'
kind: ConfigMap
metadata:
  creationTimestamp: "2023-11-09T22:46:34Z"
  labels:
    app.kubernetes.io/managed-by: openshift-gitops
    app.kubernetes.io/name: argocd-rbac-cm
    app.kubernetes.io/part-of: argocd
  name: argocd-rbac-cm
  namespace: openshift-gitops

This is the default RBAC policy that is created by the OpenShift GitOps operator. It gives role:admin rights to users that are part of the cluster-admins or system:cluster-admins group. If the user you are using is not part of the cluster-admins group it falls to the default role (role:readonly).

Note: In any OpenShift cluster deployment the group cluster-admins does not exist and is not created by default.

In an OpenShift cluster in which you use kubeadmin as the cluster-admin user there are no issues with this policy since the kubeadmin user is effectively root.

In a deployment of an OpenShift cluster that removes the kubeadmin to improve cluster security, and creates a cluster-admin user (e.g. admin), you will need to create a cluster-admins group in OpenShift and add the user to that group.

Simplest Option
In your case the simplest option to get around this issue is to create a group called cluster-admins in OpenShift and add the cluster-admin user (e.g. admin) to the group. You can do this via the OpenShift Console or doing an oc apply -f cluster-admin-group.yaml using the following manifest:

apiVersion: user.openshift.io/v1
kind: Group
metadata:
  name: cluster-admins
users:
- admin

We will be evaluating how to include this in future releases of the Validated Patterns framework.

In any case we will need to document the need to create the cluster-admins group and add the cluster-admin user to get around your issue.

Hope this helps.