Ein ClusterRoleBinding bindet eine ClusterRole an Subjekte und wirkt dabei clusterweit – in allen Namespaces und zusätzlich auf clusterweite Ressourcen. Es ist das Gegenstück zum RoleBinding, das auf einen einzelnen Namespace beschränkt ist.
Aufbau
Wie ein RoleBinding besteht ein ClusterRoleBinding aus subjects und roleRef. Es hat selbst keinen Namespace (cluster-scoped Objekt). Üblicherweise referenziert es eine ClusterRole; selten auch eine Role, die dann nur in ihrem eigenen Namespace wirkt – ein Fall, den man praktisch nie braucht.
Beispiel
Der User root erhält volle Admin-Rechte im gesamten Cluster:
kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=rootTypische Einsätze
- Cluster-Administration: Wenige Admins oder SREs bekommen die eingebaute Rolle
cluster-admin– sie kann praktisch alles. - Plattform-Komponenten: Monitoring-Systeme wie Prometheus brauchen oft eine ClusterRoleBinding, um Metriken von Nodes und Pods in allen Namespaces zu sammeln.
- CI/CD-Systeme: Ein ServiceAccount aus einem zentralen Namespace deployt damit Anwendungen in mehrere Namespaces.
Vorsicht
Ein ClusterRoleBinding ist mächtig: Fehler wirken sofort im ganzen Cluster. Least Privilege bedeutet hier, Bindungen so eng wie möglich zu halten – etwa eine eigene ClusterRole mit nur den nötigen Rechten statt cluster-admin. Die Kubernetes-API prüft jede Anfrage über den kube-apiserver gegen die gebundenen Rollen.
Verwandte Grundlagen: Kubernetes RBAC, Kubernetes, kubectl-Befehle.