Kritische Kubernetes-RBAC-Fehlkonfigurationen ermöglichen die vollständige Übernahme des Clusters

#1 — Wildcard-Berechtigungen in ClusterRoles

Die am weitesten verbreitete Fehlkonfiguration: 23 % der Cluster verfügen über benutzerdefinierte ClusterRoles mit Wildcard-Verben oder -Ressourcen (*). Teams kopieren die Rolle cluster-admin als Ausgangspunkt und vergessen, ihren Umfang einzuschränken. Ein einzelner Pod mit einem Servicekonto, das an eine solche Rolle gebunden ist, hat uneingeschränkten Zugriff auf jede Ressource in jedem Namespace — Secrets, ConfigMaps, Knoten und den API-Server selbst.

# Gefährlich: Wildcard-ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: devops-tools
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]        # ← Entspricht vollständigen Cluster-Administratorrechten

#2 — Missbrauch von Standard-Servicekonten

Jeder Kubernetes-Namespace besitzt ein default-Servicekonto, das automatisch in Pods eingebunden wird, sofern dies nicht ausdrücklich deaktiviert wurde. In 41 % der Cluster wurden dem Standard-Servicekonto in mindestens einem Namespace erweiterte Berechtigungen erteilt — häufig, weil ein Administrator während der Fehlerbehebung schnell kubectl create rolebinding ausgeführt und die Bindung anschließend nie entfernt hat. Angreifer, die in einem beliebigen Pod dieses Namespace RCE erlangen, übernehmen diese Berechtigungen sofort.

#3 — Übermäßige ClusterRoleBindings

34 % der Cluster verfügen über mehr als 10 benutzerdefinierte ClusterRoleBindings — Bindungen, die Berechtigungen über alle Namespaces hinweg erteilen. Viele davon binden weitreichende Rollen an Gruppen wie system:authenticated oder system:serviceaccounts und gewähren damit effektiv jedem authentifizierten Benutzer oder jedem Servicekonto im Cluster erweiterte Zugriffsrechte.

#4 — Ausbruch aus Namespaces über die Pod-Erstellung

Benutzer mit der Berechtigung create pods in einem beliebigen Namespace können das Dateisystem des Hosts einbinden, privilegierte Container ausführen oder Pods mit jedem beliebigen Servicekonto dieses Namespace erstellen. In 29 % der Cluster verfügen Entwickler über Rechte zur Pod-Erstellung, ohne dass Pod Security Standards durchgesetzt werden — dadurch wird ein trivialer Container-Ausbruch auf den zugrunde liegenden Knoten ermöglicht.

#5 — Automatische Token-Einbindung in privilegierten Pods

Kubernetes bindet standardmäßig Servicekonto-Token in Pods ein. In Kombination mit privilegierten Pod-Spezifikationen oder Zugriff auf das Hostnetzwerk können Angreifer das Token stehlen und sich von außerhalb des Clusters am API-Server authentifizieren. Nur 12 % der untersuchten Cluster setzen automountServiceAccountToken: false bei Workloads, die keinen API-Zugriff benötigen.

Automatisierte RBAC-Prüfung mit KENSAI

Das Kubernetes-Sicherheitsmodul von KENSAI umfasst jetzt eine automatisierte RBAC-Analyse, die jedes Servicekonto, jede Rolle und jede Bindung in Ihrem Cluster abbildet, um Pfade zur Rechteausweitung zu identifizieren. Der Scanner erzeugt eine visuelle Darstellung der Berechtigungsketten und hebt den kürzesten Pfad von jedem kompromittierten Workload zum Cluster-Administrator hervor.

Prinzip der geringsten Rechte für Servicekonten

Jeder Workload sollte über ein eigenes dediziertes Servicekonto verfügen, das nur die tatsächlich benötigten Berechtigungen besitzt. Vermeiden Sie die Bindung von ClusterRoles, wenn auf einen Namespace beschränkte Roles ausreichen. Verwenden Sie automountServiceAccountToken: false für Pods, die keinen Zugriff auf die Kubernetes API benötigen — dies trifft auf die Mehrheit der Anwendungs-Workloads zu.

Pod Security Standards durchsetzen

Kubernetes Pod Security Standards (PSS) auf der Ebene restricted verhindern, dass Pods als Root ausgeführt werden, Hostpfade einbinden oder den privilegierten Modus verwenden. Setzen Sie diese mithilfe von Pod Security Admission auf Namespace-Ebene durch. Dadurch wird der Angriffsvektor für Container-Ausbrüche beseitigt, selbst wenn die RBAC-Berechtigungen zu weitreichend sind.

Regelmäßige RBAC-Überprüfungen

Führen Sie vierteljährliche RBAC-Prüfungen ein. Überprüfen Sie alle ClusterRoleBindings, identifizieren Sie veraltete Bindungen ausgeschiedener Teammitglieder oder stillgelegter Dienste und stellen Sie sicher, dass kein Servicekonto über umfassendere Berechtigungen als erforderlich verfügt. KENSAI kann dies durch kontinuierliche Abweichungserkennung automatisieren.