Argo CD Helm Chart：Unnecessary RBAC permissions

[Yseona]

Describe the bug

The bug is that the Deployment argo-cd-argocd-server and StatefulSet argo-cd-argocd-application-controller in the charts have too much RBAC permission than they need. The service account of argo-cd-argocd-server is bound to a clusterrole (argocd-server/clusterrole.yaml) with the following permissions:

• patch/delete verb of the deployments/statefulsets/daemonsets/cronjobs/replicasets/nodes/pods/services/networkpolicies resource (ClusterRole)
• create/patch/delete verb of the jobs resource (ClusterRole)
• patch verb of the clusterroles resource (ClusterRole)
• delete verb of the ingresses resource (ClusterRole)

And the service account of argo-cd-argocd-application-controller is also bound to a clusterrole (argocd-application-controller/clusterrole.yaml) with the following permissions:

• create/patch/update/delete verb of the deployments/statefulsets/daemonsets/cronjobs/replicasets/jobs/pods/services resource (ClusterRole)
• delete verb of the ingresses resource (ClusterRole)
• patch/update/delete verb of the nodes/networkpolicies resource (ClusterRole)
• bind/escalate/patch verb of clusterroles resource (ClusterRole)

After reading the source code of argo-cd, I didn't find any Kubernetes API usages using these permissions. Besides, some of these unused permissions may have potential risks. For example, if a malicious user gains control of a Kubernetes node running an argo-cd-argocd-server pod, they can use the "patch jobs" permission to edit existing workloads, create privileged containers with malicious container images, or use the "patch nodes" permission to modify node specifications so that system-critical components with high privileges will run on the controlled node.

Related helm chart

argo-cd

Helm chart version

6.10

To Reproduce

Install the Argo CD helm chart with default values.

Expected behavior

Therefore, these permissions should be rechecked to determine if they are truly unnecessary. If they are, the issue should be fixed by removing the unnecessary permissions or by using methods from some similar CVEs (e.g., CVE-2023-26484, CVE-2023-30840).

Screenshots

No response

Additional context

No response

[yu-croco]

Hi @Yseona , thank you for opening an issue.

After reading the source code of argo-cd, I didn't find any Kubernetes API usages using these permissions.

Since argo-helm follows upstream's manifest, can you please open an issue in upstream as well? Once upstream's manifests are updated, we will also follow.

e.g.) argocd-application-controller clister role

• argo-helm: https://github.com/argoproj/argo-helm/blob/main/charts/argo-cd/templates/argocd-application-controller/clusterrole.yaml
• upstream: https://github.com/argoproj/argo-cd/blob/master/manifests/cluster-rbac/application-controller/argocd-application-controller-clusterrole.yaml

FYI: As a workaround, we can configure clusterRoleRules.rules to adjust permissions.
e.g.) https://github.com/argoproj/argo-helm/blob/main/charts/argo-cd/values.yaml#L889-L893

[Yseona]

OK

[dan-m8t]

We had the same issue for a dedicated customer instance on a shared cluster.
We ended up with a custom clusterrole like @yu-croco mentioned, like this:

rules:
- apiGroups:
  - '*'
  resources:
  - '*'
  verbs:
  - get
  - list
  - watch

Afaik Argo CD needs at least get,list,watch on all ressources. To narrow down the permissions we deploy a RoleBinding into the namespaces Argo CD is about to manage and bind that onto a ClusterRole for doing things inside that namespace. In our case it is the default "admin" ClusterRole of OpenShift which allows Argo CD to act like a project admin and thus can create all namespaced stuff but no clusterwide ressources. This comes with the drawback that the application-controller service account is able to read secrets from other namespaces, so this needs an additional layer of security, e.g. no access on the namespace where argocd is running and forbid impersonation for users. I hope the project will take more effort in multitenancy as I read alot of issues about that here.