Kubernetes RBAC: das Rollenmodell, das euer Auditor abnimmt

Was regelt Kubernetes RBAC, und was regelt es nicht?

Kubernetes RBAC ist die Autorisierung an der Kubernetes-API. Vier Objekttypen reichen: Role und ClusterRole beschreiben Rechte, RoleBinding und ClusterRoleBinding hängen diese Rechte an ein Subject, also an einen Benutzer, eine Gruppe oder einen ServiceAccount. Jede Regel besteht aus apiGroups, resources und verbs, etwa get, list, create, delete.

Zwei Eigenschaften bestimmen alles Weitere. RBAC kennt kein Deny: Alle Bindings eines Subjects addieren sich, und wer über irgendeine Gruppe cluster-admin erbt, behält den Vollzugriff. Und RBAC prüft nur den API-Zugriff, nicht das Verhalten danach.

Nicht geregelt werden: die Authentifizierung selbst, das ist euer Identity-Provider. Die Rechte, mit denen ein Container nach dem Start läuft, das macht der Security Context. Die Netz-Trennung zwischen Namespaces, dafür braucht ihr Network Policies. Und der Inhalt der Images, dafür gibt es Image Scanning.

Warum cluster-admin für alle im Audit als Erstes auffällt

Der typische Fall: Beim Cluster-Aufbau bekommt die Plattform-Gruppe cluster-admin, damit die Inbetriebnahme nicht an Rechten scheitert. Der CI-ServiceAccount bekommt dieselbe Bindung. Beides war für ein paar Wochen gedacht. Zwei Jahre später hängen Personen und Pipelines im Vollzugriff, die dort nie hingehört haben, und niemand kann sagen, wer das freigegeben hat.

Im Audit ist das die erste Frage, weil sie sich in zwei Minuten beantworten lässt. Ein Prüfer liest eure ClusterRoleBindings und sieht, wer an cluster-admin hängt, ob Rollen mit Wildcards arbeiten und ob der default-ServiceAccount Rechte trägt. Solche Befunde lassen keine Diskussion zu.

NIS2 ist über das BSIG am 06.12.2025 in Kraft getreten, und Kunden aus dem regulierten Mittelstand geben die Anforderung vertraglich an ihre Lieferanten weiter. Wer keine Antwort auf "wer darf bei euch Secrets lesen" hat, verliert nicht das Audit, sondern die Ausschreibung.

Rechte, die beim Aufbau vergeben wurden, sind der Normalfall. Rechte, die nach dem Aufbau wieder eingesammelt wurden, sind die Ausnahme.

Wie sieht ein Rollenmodell aus, das ein Auditor abnimmt?

Vier Zugriffsklassen müssen getrennt sein. Entwicklung arbeitet im eigenen Namespace. Betrieb und SRE lesen clusterweit und schreiben nur dort, wo der Betrieb es erfordert. Revision liest, mehr nicht. Die CI hat einen eigenen ServiceAccount pro Zielnamespace. Jede Zeile der Matrix könnt ihr im eigenen Cluster nachprüfen.

Was die Matrix nicht zeigt, ein Prüfer aber sehen will: wer die Vergabe freigegeben hat. Führt die Rollen als Manifeste in Git, mit Review-Pflicht. Dann ist die Freigabe der Merge-Commit.

Role oder ClusterRole: wann bindet ihr auf den Namespace, wann clusterweit?

Eine Role gilt in genau einem Namespace. Eine ClusterRole gilt clusterweit und ist die einzige Möglichkeit, Ressourcen ohne Namespace zu erfassen: Nodes, PersistentVolumes, StorageClasses, CRDs.

Der Fehler entsteht bei der Wiederverwendung. Dieselbe Rechte-Definition in zwanzig Namespaces nutzen heißt: eine ClusterRole bauen. Das ist richtig. Falsch wird es, wenn sie per ClusterRoleBinding gebunden wird statt per RoleBinding je Namespace. Über ein RoleBinding gebunden gilt eine ClusterRole nur in diesem einen Namespace. Genau so trennt ihr Definition und Reichweite.

Zweiter Punkt: Fasst die eingebauten Rollen nicht an. admin, edit, view und cluster-admin sind Standard und werden bei Updates zurückgesetzt. Wollt ihr enger schneiden, baut eigene Rollen mit eigenem Namen.

ServiceAccounts: jeder Workload bekommt seine eigene Identität

Jeder Pod läuft unter einem ServiceAccount. Gebt ihr keinen an, ist es der default des Namespace, und dessen Token wird per Voreinstellung eingehängt. Das ist der Punkt, an dem ein kompromittierter Container zum Cluster-Problem wird.

Drei Maßnahmen gehören zusammen. automountServiceAccountToken auf false setzen, am ServiceAccount und in der Pod-Spezifikation, außer der Workload spricht wirklich mit der API. Pro Anwendung ein eigener ServiceAccount, nie der default. Und dem default-ServiceAccount keine einzige Rolle binden, damit ein vergessener Pod ohne Rechte startet.

Für Zugangsdaten gilt: einhängen ja, lesen nein. Wer über die API get auf Secrets darf, zieht alle Zugangsdaten des Namespace ab. Das Einhängen als Volume braucht dieses Recht nicht.

Wie prüft ihr eure RBAC-Vergabe selbst?

Vier Befehle beantworten den Großteil der Audit-Fragen. Alle vier brauchen nur Lesezugriff und verändern nichts.

• Wer hat Vollzugriff: kubectl get clusterrolebindings -o wide, darin die Subjects an cluster-admin. Danach kubectl get rolebindings -A -o wide.
• Was darf ein Subject: kubectl auth can-i --list --as=alice -n team-a, für ServiceAccounts mit --as=system:serviceaccount:team-a:ci.
• Wer kommt an Secrets: kubectl auth can-i get secrets --as=... je Klasse durchspielen. Die Frage kommt im Audit zuerst.
• Wo stehen Wildcards: Rollen-Manifeste nach Sternchen in resources oder verbs durchsuchen. Jede Fundstelle braucht eine Begründung oder muss weg.

Erst messen, dann schneiden. can-i --list zeigt die effektive Summe aller Bindings und ist damit die einzige verlässliche Sicht. Der Blick in einzelne Rollen täuscht.

Security Context und Pod Security Standards: die Rechte nach dem Zugriff

RBAC entscheidet, wer ein Objekt anlegen darf. Womit es dann läuft, entscheidet der Security Context: runAsNonRoot, ein fester runAsUser, readOnlyRootFilesystem, allowPrivilegeEscalation auf false, gedroppte Capabilities. Ohne diese Einstellungen startet ein regulär erlaubter Pod als Root mit privilegierten Rechten.

Die Pod Security Standards fassen diese Einstellungen zu drei Stufen zusammen: privileged ohne Einschränkung, baseline gegen die bekannten Ausbrüche, restricted als engste Stufe mit Nicht-Root-Pflicht. Das löst die alte Pod Security Policy ab, die aus Kubernetes entfernt wurde. Zielbild: restricted für Anwendungs-Namespaces, baseline nur mit dokumentierter Begründung.

Wie diese Stufen technisch erzwungen werden, steht unter Policies und Admission Control. Hier zählt die Zuordnung: RBAC ist der Zugang, der Security Context sind die Rechte danach.

Die Fehler, die wir in fast jedem Cluster wiederfinden

Dazu zwei Muster, die weniger offensichtlich sind. Erstens ein Subject, das dieselben Rechte über zwei Wege erbt, Personen-Gruppe und Team-Bindung. Kappt ihr nur einen Weg, ändert sich nichts. Zweitens die Verben escalate, bind und impersonate: Wer sie hat, gibt sich selbst höhere Rechte, auch ohne cluster-admin. Diese drei gehören in keine Team-Rolle.

Rechte wegnehmen, ohne den Betrieb zu zerlegen

Rechte blind zu entziehen bricht Pipelines und kippt den ganzen Umbau. Der Weg, der funktioniert, läuft in vier Schritten.

Gibt der laufende Betrieb diese Disziplin nicht her, gehört sie in ein Betriebsmodell: Managed Kubernetes.

Was der Angriffsflächen-Check ab 850 EUR an eurem RBAC prüft

Warum mit Preis: Von 17 geprüften Anbietern hat kein einziger ein buchbares Security-Produkt mit Preis. Ihr sollt vorher wissen, was es kostet.

Was der Check ausdrücklich nicht ist

Der Angriffsflächen-Check ist ein Konfigurations-Review, kein Pentest. Wir greifen nichts an, brechen nicht aus Containern aus und testen keine Anwendungslogik. Wer einen echten Penetrationstest braucht, bekommt ihn über einen Partner, nicht von uns: anderes Format, anderer Aufwand, 8.000 EUR.

Ein Testat stellt der Check ebenfalls nicht aus, das dürfen nur akkreditierte Stellen. Ihr bekommt die Befundliste plus die Nachweise für Prüfer und Kunden.

Danach entscheidet ihr: selbst umbauen, Compliance-Snapshot für 1.250 EUR oder Retainer ab 2.500 EUR im Monat.

Verwandte Seiten im Security-Zweig

• Kubernetes Security: der Hub mit Self-Check und Angriffsflächen-Check.
• Policies und Admission Control: Durchsetzung der Pod Security Standards.
• Network Policies: Trennung im Netz, die RBAC nicht leistet.
• Image Scanning: Schwachstellen in euren Images.
• Container Security: Härtung des Containers selbst.
• Kubernetes Compliance: Nachweise für NIS2, ISO und Kundenaudits.
• Hardening-Checkliste: Kurzfassung zum Abarbeiten.

Häufige Fragen zu Kubernetes RBAC

Wie finde ich heraus, wer in meinem Cluster cluster-admin hat?

Schaut euch an, welche Subjects an die ClusterRole cluster-admin gebunden sind: kubectl get clusterrolebindings -o wide und danach die RoleBindings pro Namespace. Prüft dabei nicht nur User und Gruppen, sondern auch ServiceAccounts. In der Praxis hängt der Vollzugriff meist an einem CI-Account oder an der Gruppe, die beim Cluster-Aufbau angelegt wurde und nie wieder angefasst wurde.

Brauchen unsere Entwickler wirklich Zugriff auf Secrets?

Fast nie. Lesezugriff auf Secrets in einem Namespace bedeutet Zugriff auf alle Zugangsdaten der Anwendungen darin, auch auf Datenbank-Passwörter. Entwickler brauchen in der Regel Lese- und Schreibrechte auf Deployments, Pods, Logs und ConfigMaps im eigenen Namespace. Secrets bleiben beim Betriebsteam oder kommen aus einem externen Store und werden nur eingehängt.

Was ist der Unterschied zwischen Role und ClusterRole?

Eine Role gilt in genau einem Namespace, eine ClusterRole gilt im ganzen Cluster und für Ressourcen ohne Namespace wie Nodes, PersistentVolumes oder CRDs. Der übliche Fehler: eine ClusterRole wird gebaut, weil sie sich einfacher wiederverwenden lässt, und dann clusterweit gebunden statt über ein RoleBinding auf einen einzelnen Namespace begrenzt.

Reicht sauberes RBAC für ein NIS2- oder ISO-Audit?

Nein. RBAC deckt den Zugriffs-Teil ab, nicht die Netz-Trennung, die Härtung der Pods oder die Nachweise über Betrieb und Reaktion. NIS2 ist über das BSIG am 06.12.2025 in Kraft getreten und fragt nach dem gesamten Bild. RBAC ist der Teil, bei dem Prüfer zuerst nachfassen, weil er sich schnell und eindeutig belegen lässt.

Was passiert, wenn ich einem Team Rechte wegnehme und danach etwas bricht?

Deshalb nehmt ihr Rechte nicht blind weg. Aktiviert erst das Audit-Log der API, wertet über einige Wochen aus, welche Verben ein Account tatsächlich benutzt, und schneidet danach zu. Für den Einzelfall prüft ihr mit kubectl auth can-i vor dem Umbau. Rollt die neue Bindung pro Namespace aus, nicht für den ganzen Cluster auf einmal.

Wie hängen RBAC, Security Context und Pod Security Standards zusammen?

RBAC entscheidet, wer ein Objekt anlegen darf. Der Security Context entscheidet, mit welchen Rechten der Container dann läuft, etwa als Nicht-Root und ohne privilegierte Rechte. Die Pod Security Standards fassen diese Einstellungen zu den Stufen privileged, baseline und restricted zusammen. Ohne beides nützt ein sauberes Rollenmodell wenig, weil ein erlaubter Pod trotzdem zu viel darf.

Der nächste Schritt