dahrens
commented
3 years ago I thought exactly the same and agree that the default privileges of the service account argocd-applicaton-controller are to elevated.
However argocd allows you to reconfigure this (with a few drawbacks).
[...] configure the list of included resources using the resource.inclusions setting. By default, all resource group/kinds are included.
I used the inclusion and ended up with something that I attach below this comment - which does not include Secrets, ClusterRoleBindings and ClusterRoleBindings and some apiGroups like certificates.k8s.io, crd.projectcalico.org, and few others.
The drawbacks are quite clear:
- you can no longer deploy anything that relies on "missing" resources (
Secrets,ClusterRoleBindingsandClusterRoleBindings) using argocd - including argocd itself :) - You need to pin the do everything ClusterRole to each namespace - cumbersome - but common when you want to achieve some basic security.
Another interesting issue is #5275 which gives some insight in the reasons behind the elevated sa. From my point of view it is a bit unfortunate that global read access is required for the synchronization - otherwise it would be possible to grant access to secrets using a RoleBinding for each namespace that should be managed by argocd. Not that elegant - but argocd is no longer cluster admin.
In fact cluster wide read access reveals all secrets and grants access to impersonate all other ServiceAccounts. I understand that a software that is meant to be used to actually control (big) parts of the cluster needs high privileges - but following the principle of least privileges is actually quite difficult using argocd - or do I miss something (justed dived in for ~20 hours).
I'd prefer that it does not need to have read access for several namespaces like e.g. kube-system at all. Despite that issue I like argocd a lot - good work :+1: - I hope I missed something in my analysis.
kubectl edit configmap argocd-cm -n argocddata:
resource.inclusions: |
- apiGroups:
- ""
kinds:
- ConfigMap
- Endpoints
- LimitRange
- Namespace
- PersistentVolumeClaim
- PersistentVolume
- Pod
- PodTemplate
- ReplicationController
- ResourceQuota
- ServiceAccount
- Service
clusters:
- "*"
- apiGroups:
- "rbac.authorization.k8s.io/v1"
kinds:
- RoleBinding
- Role
clusters:
- "*"
- apiGroups:
- "networking.k8s.io"
- "extensions"
- "discovery.k8s.io"
- "cert-manager.io"
- "batch"
- "argoproj.io"
- "apps"
- "apiextensions.k8s.io"
- "apiregistration.k8s.io"
- "acme.cert-manager.io"
kinds:
- "*"
clusters:
- "*"
kind: ConfigMapAnd ClusterRole that looks like that:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
labels:
app.kubernetes.io/component: application-controller
app.kubernetes.io/name: argocd-application-controller
app.kubernetes.io/part-of: argocd
name: argocd-application-controller
rules:
- apiGroups:
- ""
resources:
- configmaps
- endpoints
- persistentvolumeclaims
- persistentvolumeclaims/status
- pods
- replicationcontrollers
- replicationcontrollers/scale
- serviceaccounts
- services
- services/status
- persistentvolumes
- podtemplates
- bindings
- events
- limitranges
- namespaces/status
- pods/log
- pods/status
- replicationcontrollers/status
- resourcequotas
- resourcequotas/status
- namespaces
verbs: [get, list, watch]
- apiGroups:
- "networking.k8s.io"
- "extensions"
- "discovery.k8s.io"
- "cert-manager.io"
- "batch"
- "argoproj.io"
- "apps"
- "apiextensions.k8s.io"
- "apiregistration.k8s.io"
- "acme.cert-manager.io"
resources:
- "*"
verbs: [get, list, watch]
- nonResourceURLs:
- '*'
verbs: [get, list, watch]Together with the old ClusterRole having a new name argocd-application-controller-namespace-admin:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
labels:
app.kubernetes.io/name: argocd-application-controller
app.kubernetes.io/part-of: argocd
app.kubernetes.io/component: application-controller
name: argocd-application-controller-namespace-admin
rules:
- apiGroups:
- '*'
resources:
- '*'
verbs:
- '*'
- nonResourceURLs:
- '*'
verbs:
- '*'Bound to several namespaces like that:
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: argocd-application-controller-foo
namespace: foo
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: argocd-application-controller-namespace-admin
subjects:
- kind: ServiceAccount
name: argocd-application-controller
namespace: argocd
aelbarkani
loreleimccollum-work
lgoral
lorelei-rupp-imprivata
ronmegini
rbizzell-collibra
ogunleye0720
ivan-cai
Pionerd
Summary
Please define a more restricted minimum necessary cluster role permissions for the argocd-applicaton-controller and argocd-manager permissions instead of the current cluster wide get, list, watch.
https://argoproj.github.io/argo-cd/getting_started/
"The rules of the argocd-manager-role role can be modified such that it only has create, update, patch, delete privileges to a limited set of namespaces, groups, kinds. However get, list, watch privileges are required at the cluster-scope for Argo CD to function."
Motivation
We would like to secure the cluster as good as possible and the service account have too much privileges. For example the default cluster role will allow the service account to read any other secret and it makes possible for privilege escalation.
Example description there: https://kubernetes.io/docs/reference/access-authn-authz/rbac/ -> view cluster role:
"Allows read-only access to see most objects in a namespace. It does not allow viewing roles or role bindings.
This role does not allow viewing Secrets, since reading the contents of Secrets enables access to ServiceAccount credentials in the namespace, which would allow API access as any ServiceAccount in the namespace (a form of privilege escalation)."
The builtin cluster role view have more restrictions and it will be great if argocd have similar in the documentation.
Proposal
It would be good if a more restricted default cluster role is defined and documented then the end users can define more roles to allow more permissions only on the target objects.