Eine ClusterRole ist ein RBAC-Objekt in Kubernetes, das Berechtigungen clusterweit bündelt – also ohne Beschränkung auf einen einzelnen Namespace. Während eine Role immer an genau einen Namespace gebunden ist, gilt eine ClusterRole für den gesamten Cluster.

Was eine ClusterRole kann

  • Clusterweite Ressourcen: Nodes, Namespaces, Persistent Volumes, ClusterRoles und ClusterRoleBindings lassen sich nur über ClusterRoles berechtigen – eine Role kann das nicht.
  • Nicht-Ressourcen-Endpunkte: Pfade wie /healthz oder /version der Kubernetes-API werden über ClusterRoles abgedeckt (Feld nonResourceURLs).
  • Namespace-Ressourcen überall: Wird eine ClusterRole mit einer ClusterRoleBinding gebunden, wirken ihre Namespace-Berechtigungen (etwa pods, configmaps) in allen Namespaces.

Aufbau

Der Aufbau entspricht einer Role: rules definieren apiGroups, resources und verbs, optional resourceNames für einzelne Objekte. Ein Beispiel für eine ClusterRole, die Pods clusterweit lesen darf:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

Wirksamkeit über Bindings

Eine ClusterRole allein verleiht noch keine Rechte – sie wird erst durch ein RoleBinding (nur im jeweiligen Namespace) oder ein ClusterRoleBinding (clusterweit) an Subjekte gebunden. Ein RoleBinding kann dabei eine ClusterRole referenzieren, wirkt dann aber nur auf die Namespace-Ressourcen im eigenen Namespace – clusterweite Ressourcen wie Nodes werden dadurch nicht freigeschaltet.

Aggregierte ClusterRoles

Die eingebauten Rollen admin, edit und view sind aggregierte ClusterRoles: Über das Feld aggregationRule und Label-Selektoren setzen sie sich aus kleineren ClusterRoles zusammen. Eigene ClusterRoles, die passende Labels tragen, erweitern die Standardrollen automatisch – so lassen sich auch Rechte für Custom Resources nachrüsten.

Verwandte Grundlagen: Kubernetes RBAC, Kubernetes, kubectl-Befehle.