Kubernetes RBAC: Best Practices für den Mittelstand

RBAC — Role-Based Access Control — ist in Kubernetes seit Version 1.8 der Standard für Zugriffssteuerung. In der Praxis sieht die Konfiguration trotzdem häufig so aus: ein ServiceAccount mit cluster-admin, weil es schnell funktioniert hat. Dieser Artikel erklärt, warum das ein Sicherheitsproblem ist und wie eine saubere RBAC-Struktur konkret aussieht.

Warum RBAC kein optionales Feature ist

In einem Kubernetes-Cluster teilen sich Workloads, CI/CD-Pipelines, Monitoring-Agenten und Entwickler dieselbe API. Ohne klare Zugriffssteuerung kann ein kompromittiertes Pod-Secret oder ein zu weit gefasster ServiceAccount ausreichen, um Cluster-weite Kontrolle zu erlangen. BSI-Grundschutz (SYS.1.6) und NIS2 adressieren genau diesen Angriffsvektor.

RBAC löst das Problem durch das Prinzip des geringsten Privilegs (Least Privilege): Jeder Akteur — menschlich oder maschinell — erhält exakt die Berechtigungen, die er für seine Aufgabe benötigt. Nicht mehr.

Die vier RBAC-Objekte und ihr Zusammenspiel

Kubernetes RBAC besteht aus vier Ressourcentypen. Das Verständnis ihrer Beziehungen ist Voraussetzung für eine korrekte Konfiguration:

• Role — Definiert Berechtigungen innerhalb eines einzelnen Namespace. Geeignet für applikationsspezifische Zugriffsregeln.
• ClusterRole — Definiert Berechtigungen cluster-weit oder für nicht-namespaced Ressourcen (Nodes, PersistentVolumes, ClusterRoles selbst).
• RoleBinding — Verknüpft eine Role oder ClusterRole mit einem Subject (User, Group, ServiceAccount) innerhalb eines Namespace.
• ClusterRoleBinding — Verknüpft eine ClusterRole mit einem Subject cluster-weit. Sparsam einsetzen.

Praxisbeispiel: CI/CD-Pipeline mit minimalen Rechten

Ein häufiger Fehler: Die Deployment-Pipeline erhält cluster-admin, weil Helm-Charts über mehrere Namespaces deployen soll. Die sichere Alternative:

# ServiceAccount für die Pipeline
apiVersion: v1
kind: ServiceAccount
metadata:
  name: ci-deployer
  namespace: production
---
# ClusterRole mit exakt den benötigten Rechten
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: deployer
rules:
  - apiGroups: ["apps"]
    resources: ["deployments", "replicasets"]
    verbs: ["get", "list", "watch", "create", "update", "patch"]
  - apiGroups: [""]
    resources: ["services", "configmaps"]
    verbs: ["get", "list", "watch", "create", "update", "patch"]
  - apiGroups: [""]
    resources: ["secrets"]
    verbs: ["get", "list"]   # kein create/update für Secrets
---
# RoleBinding beschränkt auf den production-Namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ci-deployer-binding
  namespace: production
subjects:
  - kind: ServiceAccount
    name: ci-deployer
    namespace: production
roleRef:
  kind: ClusterRole
  name: deployer
  apiGroup: rbac.authorization.k8s.io

Die Pipeline kann jetzt Deployments im production-Namespace verwalten — aber keine Secrets schreiben, keine Nodes ansehen, keine anderen Namespaces berühren. Ein kompromittierter Pipeline-Token hat damit einen radikal eingeschränkten Blast Radius.

Aggregierte ClusterRoles: Wiederverwendung ohne Duplikation

Kubernetes erlaubt es, ClusterRoles über Labels zu aggregieren. Das ist besonders für Operator-Entwickler und Plattform-Teams nützlich:

# Basis-ClusterRole mit aggregation-Regel
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: monitoring-viewer
  labels:
    rbac.kubewerk.de/aggregate-to-platform-read: "true"
rules:
  - apiGroups: ["monitoring.coreos.com"]
    resources: ["prometheusrules", "servicemonitors"]
    verbs: ["get", "list", "watch"]

Jede ClusterRole mit dem Label rbac.kubewerk.de/aggregate-to-platform-read: "true"wird automatisch in die übergeordnete Aggregations-Role eingebunden. Neue Operatoren erweitern so den Plattform-Read-Zugang, ohne bestehende Bindings anzufassen.

Berechtigungen auditieren: Was hat wer wirklich?

Das kubectl auth can-i-Kommando ist der schnellste Weg zur Überprüfung:

# Kann der ServiceAccount ci-deployer Secrets lesen?
kubectl auth can-i get secrets   --namespace production   --as system:serviceaccount:production:ci-deployer

# Alle Berechtigungen eines ServiceAccounts auflisten
kubectl auth can-i --list   --namespace production   --as system:serviceaccount:production:ci-deployer

Für einen vollständigen Cluster-Überblick empfiehlt sich das Open-Source-Tool rakkess oder kubectl-who-can. Beide lassen sich ohne Cluster-Admin-Rechte betreiben und liefern eine tabellarische Übersicht aller Subjects und ihrer Verbs pro Ressource.

ServiceAccount-Token: Automount abschalten

Kubernetes mounted automatisch ein ServiceAccount-Token in jeden Pod — auch wenn die Applikation die Kubernetes-API nie aufruft. Das Token ist von jedem Prozess im Container lesbar. Die sichere Standardkonfiguration:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app
  namespace: production
automountServiceAccountToken: false   # Default überschreiben
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  template:
    spec:
      serviceAccountName: my-app
      automountServiceAccountToken: false   # Doppelt sichern

Wenn die Applikation tatsächlich API-Zugang benötigt, verwenden Sie projected volumes mit kurzer Token-Laufzeit (expirationSeconds: 3600) statt des langlebigen Standard-Tokens.

RBAC und Namespace-Isolation: Was RBAC nicht kann

Ein häufiges Missverständnis: RBAC kontrolliert den Zugriff auf die Kubernetes-API, aber nicht den Netzwerkverkehr zwischen Pods. Ein Pod im Namespace staging kann ohne Netzwerkrichtlinien trotzdem TCP-Verbindungen in den Namespace production aufbauen — RBAC verhindert das nicht. Für vollständige Isolation brauchen Sie zusätzlich NetworkPolicies (oder Cilium Network Policies) und ggf. eine Admission-Controller-Lösung wie Kyverno.

RBAC ist also eine notwendige, aber keine hinreichende Sicherheitsmaßnahme. Es gehört in eine Defence-in-Depth-Strategie zusammen mit Pod Security Standards, NetworkPolicy und Supply-Chain-Kontrollen.

Häufige Fehler in der Praxis

• Wildcards in Rules: verbs: ["*"] oder resources: ["*"] — selten notwendig, oft ein Überbleibsel aus der Schnellkonfiguration. Jede Wildcard sollte begründet und dokumentiert sein.
• Zu viele ClusterRoleBindings: Die meisten Berechtigungen gehören in einen Namespace-Scope. ClusterRoleBindings gelten cluster-weit und sollten die Ausnahme sein.
• Verwaiste Bindings: Nach dem Löschen eines ServiceAccounts bleiben Bindings oft stehen. kubectl get rolebindings,clusterrolebindings -A und ein Abgleich mit vorhandenen Subjects gehört ins reguläre Housekeeping.
• Geteilte ServiceAccounts: Mehrere Applikationen oder Pipelines teilen sich einen ServiceAccount „aus Bequemlichkeit". Jede Workload sollte einen eigenen ServiceAccount mit maßgeschneiderten Rechten haben.

Fazit

Kubernetes RBAC ist kein Thema, das man einmal konfiguriert und vergisst. In einem wachsenden Cluster mit neuen Operatoren, CI/CD-Pipelines und Teams schleichen sich Permission-Creep und Wildcard-Regeln schnell ein. Ein strukturiertes RBAC-Konzept — mit klaren Namenskonventionen, Aggregations-Rollen und regelmäßigem Audit — ist die Grundlage für einen sicheren Cluster-Betrieb.

Wenn Sie unsicher sind, ob Ihr aktuelles RBAC-Setup dem Least-Privilege-Prinzip entspricht, hilft ein strukturierter Blick von außen weiter.

Mehr erfahren: Kubernetes-Beratung oder Audit buchen.