Kubernetes RBAC (Role Based Access Control) legt fest, wer im Cluster welche Aktion auf welcher Ressource ausführen darf, und zwar über die Kombination aus Rollen und Bindings. Bei jeder Anfrage an die API prüft Kubernetes, ob der anfragende Mensch, die Gruppe oder der Service Account über eine passende Berechtigung verfügt, sonst lehnt der API-Server die Anfrage ab. Ein Satz vorweg, weil er das häufigste Missverständnis ausräumt: RBAC ist keine Benutzerverwaltung. Wer du bist, klärt die Authentifizierung über Zertifikat, Token oder einen angebundenen Identitätsanbieter. RBAC beantwortet erst die Frage danach, was du als diese bereits erkannte Identität tun darfst. Benutzerkonten legt Kubernetes selbst nie an. Ohne durchdachte RBAC-Konfiguration bekommst du in den meisten Clustern entweder viel zu wenig oder viel zu weiten Zugriff, und beides ist in Produktion unbrauchbar.
Ich betreibe produktionsreife Kubernetes-Cluster mit Rollen und Rechten nach genau diesem Modell und habe das Kubernetes-Praxisbuch bei Rheinwerk geschrieben (2024). Diesen Beitrag findest du zusammen mit allen anderen Kubernetes-Themen auf meiner Seite Kubernetes.
Wer darf was: das RBAC-Modell in Kubernetes
Bevor du eine einzige Rolle anlegst, hilft ein Blick auf die drei Arten von Akteuren, für die RBAC überhaupt gilt. Menschen greifen typischerweise über eine Kubeconfig auf den Cluster zu, ihr Name steckt im Common-Name-Feld ihres Zertifikats oder kommt von einem externen Identity Provider. Gruppen fassen mehrere Menschen zusammen, damit du nicht jedem Entwickler einzeln eine Rolle zuweist, sondern der ganzen Gruppe auf einmal. Service Accounts schließlich sind die clustereigene Identität für Pods: Jeder Namespace bekommt automatisch einen Default Service Account, den Anwendungen und Prozesse in ihren Pods nutzen, um mit der Kubernetes-API zu sprechen.
Nutzer und Gruppen verwaltet Kubernetes nicht selbst, dafür braucht es eine externe Anbindung, etwa über ein Zertifikat, OIDC oder ein Tool, das eine passende Kubeconfig für jeden Menschen ausstellt. Service Accounts dagegen sind waschechte Kubernetes-Objekte: Du legst sie an, bindest ihnen eine Rolle zu und trägst sie im Pod ein.
Damit ein Akteur überhaupt etwas darf, brauchst du zwei Teile: eine Rolle, die beschreibt, welche Aktionen auf welchen Ressourcen erlaubt sind, und ein Binding, das diese Rolle einem Akteur zuweist. Ohne Binding bleibt jede noch so fein definierte Rolle wirkungslos, sie liegt nur als Definition im Cluster, ohne dass jemand davon profitiert.
Role, ClusterRole und die passenden Bindings
Eine Role gilt nur innerhalb eines einzelnen Namespace, eine ClusterRole gilt clusterweit oder dient als wiederverwendbare Vorlage. Zu jeder der beiden gehört ein passendes Binding, das die Rolle einem Akteur zuweist:
| Objekt |
Gültigkeitsbereich |
Aufgabe |
| Role |
ein Namespace |
definiert Rechte für Ressourcen innerhalb dieses Namespace |
| ClusterRole |
der ganze Cluster oder wiederverwendbar |
definiert Rechte für clusterweite Ressourcen oder als Vorlage für mehrere Namespaces |
| RoleBinding |
ein Namespace |
weist eine Role oder ClusterRole einem Akteur innerhalb dieses Namespace zu |
| ClusterRoleBinding |
der ganze Cluster |
weist eine ClusterRole einem Akteur clusterweit zu |
Ein Detail, das in der Praxis oft übersehen wird: Du kannst eine ClusterRole auch über ein ganz normales RoleBinding zuweisen. Dann gelten die Rechte nur innerhalb des Namespace, in dem das RoleBinding liegt, obwohl die Rolle selbst clusterweit definiert ist. Das erspart dir, dieselbe Rolle mehrfach als eigene Role in jedem Namespace neu zu schreiben.
Innerhalb einer Rolle bestimmen drei Felder, was genau erlaubt ist: apiGroups gruppiert verwandte Ressourcen, die leere Gruppe "" steht für Kernressourcen wie Pods oder Services, apps zum Beispiel für Deployments. resources listet die konkreten Objekttypen auf, für die die Rolle gilt. verbs schließlich legt fest, welche Operationen erlaubt sind, darunter get, list, watch, create, update, patch, delete und deletecollection. Mit kubectl api-resources --sort-by name -o wide siehst du alle Objekttypen deines Clusters auf einen Blick, inklusive der API-Gruppe, in der sie stecken.
Das folgende Beispiel erlaubt einer Gruppe von Entwicklern, Deployments im Namespace team-shop zu lesen, aber nicht zu verändern:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: deployment-reader
namespace: team-shop
rules:
- apiGroups: ["apps"]
resources: ["deployments"]
verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: team-shop-read-deployments
namespace: team-shop
subjects:
- kind: Group
name: team-shop-dev
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: deployment-reader
apiGroup: rbac.authorization.k8s.io
Die Role definiert die Rechte, das RoleBinding weist sie der Gruppe team-shop-dev zu, und beides gilt ausschließlich im Namespace team-shop. Nach dem Least-Privilege-Prinzip vergibst du dabei immer nur die Verben und Ressourcen, die eine Rolle tatsächlich braucht, nicht mehr.
Service Accounts: Identität für Pods und Automatisierung
Der Default Service Account eines Namespace hat aus gutem Grund praktisch keine Rechte, er dient nur der Authentifizierung. Für jede Anwendung, die tatsächlich mit der Kubernetes-API sprechen soll, legst du deshalb einen eigenen, dedizierten Service Account an und bindest ihm über eine Role oder ClusterRole genau die Rechte zu, die die Anwendung braucht.
Ob das funktioniert hat, prüfst du am besten, bevor der Pod überhaupt läuft. kubectl auth can-i simuliert eine Anfrage mit den Rechten eines beliebigen Akteurs:
kubectl auth can-i list deployments \
--as=system:serviceaccount:team-shop:ci-deployer \
--namespace=team-shop
Der Befehl beantwortet mit yes oder no, ohne dass du dafür einen echten Pod ausrollen musst. Genauso findest du mit kubectl auth can-i --list --as=system:serviceaccount:team-shop:ci-deployer alle Rechte eines Service Account auf einen Blick, was bei der Fehlersuche viel schneller geht als jede einzelne Berechtigung von Hand nachzuvollziehen.
Braucht ein Pod gar keinen Zugriff auf die Kubernetes-API, deaktivierst du das automatische Einhängen des Tokens am besten ganz mit automountServiceAccountToken: false in der Pod-Spezifikation. Braucht der Pod das Token, hängt das Kubelet es als projiziertes Volume ein, mit begrenzter Gültigkeit und automatischer Erneuerung, statt es dauerhaft als Secret im Namespace liegen zu lassen. Wie du andere sensible Werte in einen Pod bekommst, steht in ConfigMap und Secret in Kubernetes.
Ein Entwicklerteam auf einen Namespace beschränken
Ein Muster, das ich in fast jedem Kundencluster einrichte: Jedes Team bekommt einen eigenen Namespace, mehr dazu in Kubernetes Namespaces richtig nutzen, und ein RoleBinding, das dem Team innerhalb dieses Namespace weitreichende Rechte gibt, außerhalb davon aber gar keine.
Kubernetes bringt dafür bereits passende ClusterRoles mit: view für reinen Lesezugriff, edit für das Anlegen und Ändern der meisten Objekte ohne Rechteverwaltung, admin zusätzlich mit der Möglichkeit, selbst weitere Rollen im Namespace zu vergeben, und cluster-admin für uneingeschränkten Zugriff auf den gesamten Cluster. Für ein Entwicklerteam reicht in aller Regel edit, gebunden über ein namespace-scoped RoleBinding:
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: team-shop-edit
namespace: team-shop
subjects:
- kind: Group
name: team-shop-dev
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: edit
apiGroup: rbac.authorization.k8s.io
Damit kann das Team in seinem eigenen Namespace nahezu alles, sieht aber weder die Objekte anderer Teams noch clusterweite Ressourcen wie Nodes oder Namespaces selbst. Das ist der Unterschied zwischen einem Team, das produktiv arbeiten kann, und einem Team, das aus Versehen einen fremden Namespace verändert.
Rechte prüfen und typische RBAC-Fehler vermeiden
Der häufigste Fehler, den ich in gewachsenen Clustern sehe, ist die pragmatische Lösung unter Zeitdruck: cluster-admin für alle, weil sonst ständig eine Berechtigung fehlt. Das funktioniert, bis genau ein kompromittierter Pod oder ein falsch gesetztes Kubeconfig reicht, um den ganzen Cluster zu übernehmen. Genauso riskant sind Wildcards in resources oder verbs: Ein Stern bei den Verben entspricht praktisch cluster-admin für die betroffenen Ressourcen, nur unauffälliger im Manifest.
Weitere RBAC Best Practices aus meiner Praxis: Bindings immer an Gruppen statt an einzelne Menschen, damit du beim Teamwechsel eine Gruppenmitgliedschaft änderst statt zehn Bindings zu suchen. Rechte regelmäßig auditieren, nicht nur beim Anlegen: kubectl auth can-i --list --as=<subjekt> zeigt dir für jeden Akteur, was er aktuell wirklich darf, und deckt vergessene Bindings zuverlässig auf. Und ein Blick in kubectl get rolebindings,clusterrolebindings -A gehört für mich zum festen Bestandteil jeder Sicherheitsprüfung, weil sich dort über Monate erstaunlich viel ansammelt, das niemand mehr braucht.
RBAC für GitOps, CI und Operatoren
Automatisierte Akteure brauchen genauso durchdachte Rollen wie Menschen, oft sogar dringender, weil sie nicht mitdenken, wenn eine Berechtigung zu weit gefasst ist. Eine CI-Pipeline, die Deployments in einen Namespace ausrollt, bekommt einen eigenen Service Account mit einer Role, die genau die dafür nötigen Ressourcen und Verben umfasst, aber zum Beispiel keinen Zugriff auf Secrets in fremden Namespaces.
Ein GitOps-Controller, der viele Namespaces gleichzeitig im Blick behält, braucht dagegen fast zwangsläufig eine ClusterRole, weil er clusterweit Objekte lesen und abgleichen muss. Sinnvoll ist trotzdem, die Schreibrechte so eng wie möglich auf die tatsächlich verwalteten Projekte oder Anwendungen zu begrenzen, statt eine einzige, sehr mächtige ClusterRole für alles zu verwenden. Operatoren, die eigene benutzerdefinierte Ressourcen mitbringen, brauchen ebenfalls eine ClusterRole, weil sie ihre CRDs clusterweit beobachten, die konkreten Instanzen dieser Ressourcen lassen sich aber trotzdem über Namespaces und zusätzliche Rollen weiter eingrenzen. Wer hier von Anfang an mit möglichst kleinen Rollen arbeitet, tauscht später nicht den kompletten Cluster gegen einen einzigen kompromittierten Automatisierungs-Account.
Häufige Fragen
Was ist der Unterschied zwischen Role und ClusterRole?
Eine Role gilt nur innerhalb des Namespace, in dem sie liegt, eine ClusterRole gilt entweder clusterweit oder dient als wiederverwendbare Vorlage, die du über ein RoleBinding auch nur in einem einzelnen Namespace wirksam machen kannst. Für reine Namespace-Rechte reicht meist eine Role, für clusterweite Ressourcen wie Nodes oder für wiederverwendbare Rollenvorlagen brauchst du eine ClusterRole.
Wie gebe ich einem Nutzer nur Lesezugriff?
Binde die eingebaute ClusterRole view über ein RoleBinding an den Nutzer oder seine Gruppe im gewünschten Namespace, dann kann er dort alles ansehen, aber nichts verändern. Für einen einzelnen, sehr eng begrenzten Lesezugriff, etwa nur auf Deployments, definierst du stattdessen eine eigene Role mit den Verben get, list und watch.
Wie sehe ich, welche Rechte ein Service Account hat?
Am schnellsten mit kubectl auth can-i --list --as=system:serviceaccount:<namespace>:<name>. Der Befehl listet alle Ressourcen und Verben auf, die der Service Account tatsächlich nutzen darf, ohne dass du erst alle Rollen und Bindings von Hand zusammensuchen musst.
Reicht RBAC als Absicherung für einen Kubernetes-Cluster?
Nein, RBAC regelt nur, wer welche Aktion auf welcher Kubernetes-Ressource ausführen darf, nicht was innerhalb eines Containers passiert. Ein Pod mit zu weiten Container-Rechten kann trotz sauberem RBAC den Node gefährden, dafür brauchst du zusätzlich Pod Security Standards und eine laufende Kontrolle des Cluster-Verhaltens.
Wie du weitermachst
Der nächste Baustein für einen sicheren Cluster ist der Security Context einzelner Pods, dazu mehr in Pod Security Standards in Kubernetes. Mein Vorschlag für heute: Lauf mit kubectl auth can-i --list durch deine wichtigsten Namespaces und prüfe, wie viele Bindings dort tatsächlich noch gebraucht werden. Die vollständige Referenz aller RBAC-Objekte findest du in der Kubernetes-Dokumentation zu RBAC, Details zur Authentifizierung von Nutzern in der Dokumentation zur Authentifizierung.
Ausführlich mit allen Beispielen steht das in Kapitel 7 meines Kubernetes-Praxisbuchs bei Rheinwerk.
