Kubernetes RBAC: Zugriffskontrolle mit Rollen – einfach erklärt

RBAC (Role-Based Access Control, rollenbasierte Zugriffskontrolle) ist das Autorisierungsverfahren von Kubernetes. Es legt fest, wer welche Aktionen an welchen Ressourcen ausführen darf – etwa wer Pods lesen, Deployments ändern oder Secrets verwalten darf. Der kube-apiserver prüft bei jeder Anfrage die RBAC-Regeln, bevor er den Zugriff erlaubt oder ablehnt.

Die vier Bausteine

RBAC besteht aus vier API-Objekten, die immer zusammenspielen:

  • Role: bündelt Berechtigungen für einen bestimmten Namespace.
  • ClusterRole: wie eine Role, wirkt aber clusterweit – für Nicht-Namespace-Ressourcen wie Nodes oder als wiederverwendbare Vorlage.
  • RoleBinding: weist eine Role oder ClusterRole einem Nutzer, einer Gruppe oder einem ServiceAccount innerhalb eines Namespace zu.
  • ClusterRoleBinding: bindet eine ClusterRole clusterweit an Subjekte.

Eine Role definiert also nur was erlaubt ist; erst das Binding sagt wem. Ohne Binding bleibt die Rolle wirkungslos.

Regeln und Verben

Jede Role enthält rules mit drei Feldern: apiGroups (welche API-Gruppe, z. B. apps oder leer für Core), resources (z. B. pods, deployments) und verbs (erlaubte Aktionen wie get, list, watch, create, update, patch, delete). Ein Minimalbeispiel:

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

Die dazugehörige Bindung nennt das Subjekt im Format system:serviceaccount:<namespace>:<name>:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: ServiceAccount
  name: build-robot
  namespace: default
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io/v1

ClusterRole und ClusterRoleBinding

Eine ClusterRole wird für Ressourcen ohne Namespace genutzt (Nodes, PersistentVolumes, Namespaces selbst) oder wenn dieselben Rechte in mehreren Namespaces gelten sollen. Die eingebaute ClusterRole cluster-admin erlaubt alles im gesamten Cluster und ist an das gleichnamige ClusterRoleBinding gebunden – sie sollte nur Menschen und Komponenten erhalten, die den Cluster wirklich vollständig verwalten.

Gute Praxis

  • Least Privilege: immer nur die Rechte geben, die eine Aufgabe wirklich braucht – niemals cluster-admin für Standard-Workloads.
  • Rollenzuweisung an ServiceAccounts statt an echte Nutzer: Anwendungen erhalten eigene Konten, nie persönliche Admin-Zugänge.
  • Gruppen statt Einzelner: Bindings auf Gruppen sind leichter zu pflegen als viele Einzel-Bindings.
  • Regelmäßig prüfen: kubectl auth can-i --list zeigt, welche Rechte ein Subjekt tatsächlich hat. Die Impersonation dehnt diese Prüfung auf andere Identitäten aus.

RBAC ergänzt die Autorisierung als zweite Stufe nach der Authentifizierung: Zuerst wird die Identität geprüft, dann entscheidet RBAC, was diese Identität darf. Details zur Identität für Pods finden Sie bei ServiceAccounts, zur Struktur der Rollen beim Artikel Kubernetes Role.