kube-reaper

Kubernetes RBAC-Angriffspfad-Mapper. Er ermittelt, was deine Identität tun kann, markiert gefährliche Berechtigungen und verkettet sie zu mehrstufigen Pfaden bis zur Kompromittierung des Clusters.

Entwickelt für Red-Teamer und Penetrationstester.

Was es tut

kube-reaper scannt einen Kubernetes-Cluster aus jeder Identität (Benutzer, Service Account, Gruppe) und erzeugt:

• 55 gefährliche Berechtigungsmuster mit Schweregradbewertungen und Angriffsanweisungen
• 18 Angriffskettentypen, die Berechtigungen zu mehrstufigen Eskalationspfaden verknüpfen
• Rekursives Identitäts-Pivoting, das SA-Token-Secrets liest und Token prägt, um transitiven Zugriff über Identitäten hinweg zu kartieren
• Pod-Pivot-Mapping, das Exec-Zugriff, laufende Pods und Service-Account-Berechtigungen verbindet
• Erkennung gefährlicher Pods, die privilegierte Container, Host-Mounts, Runtime-Sockets und exponierte Secrets markiert
• RBAC-Graph-Enumeration, die alle Identitäten auf ihre effektiven Berechtigungen abbildet und überprivilegierte Pivot-Ziele markiert
• 31 CRD-Bedrohungsmuster für ArgoCD, Flux, Istio, cert-manager, Kyverno, Gatekeeper, Tekton, Crossplane, Calico und andere
• Secret-Triage, die zugängliche Secrets nach Typ klassifiziert (SA-Token, Registry-Credentials, TLS-Zertifikate, SSH-Schlüssel, opaque)
• Pod-Kontext-Analyse für Container-Escape-Vektoren, Linux-Capabilities, Cloud-IMDS und Netzwerkschnittstellen
• kubectl-loser Modus für lokale Prüfungen, wenn der API-Server von einem Pod aus nicht erreichbar ist

Installation

Erfordert eine Rust-Toolchain (rustup + stable).

git clone https://github.com/youruser/kube-reaper.git
cd kube-reaper
cargo build --release

Das Binary befindet sich unter target/release/kube-reaper.

Statisches Binary (empfohlen für Deployment)

Ein musl-Build erzeugt ein vollständig statisches Binary ohne Abhängigkeiten. Es funktioniert auf jedem Linux-x86_64-System.

rustup target add x86_64-unknown-linux-musl
cargo build --release --target x86_64-unknown-linux-musl

Das Binary befindet sich unter target/x86_64-unknown-linux-musl/release/kube-reaper (~5,4 MB).

# Copy to a Kubernetes node
scp target/x86_64-unknown-linux-musl/release/kube-reaper user@node:/tmp/

# Copy into a running pod
kubectl cp target/x86_64-unknown-linux-musl/release/kube-reaper mynamespace/mypod:/tmp/kube-reaper

Schnellstart

# Scan with current kubeconfig
kube-reaper

# Scan a specific namespace
kube-reaper -n production

# Scan with a stolen SA token
kube-reaper --token <JWT> --server https://10.0.0.1:6443

# Scan as a different user (requires impersonate permissions)
kube-reaper --as-user system:serviceaccount:development:code-server

# Recursive identity pivot (read SA tokens, mint new tokens, map transitive access)
kube-reaper --pivot

# Pivot with custom depth (default: 3)
kube-reaper --pivot --pivot-depth 5

# Show only critical and high findings
kube-reaper -s high

# Output JSON
kube-reaper -o json

# Save JSON report to file
kube-reaper -w results.json

CLI-Referenz

Usage: kube-reaper [OPTIONS]

Options:
  -n, --namespace <NAMESPACE>     Target namespace (default: all accessible)
  -k, --kubeconfig <KUBECONFIG>   Path to kubeconfig file
      --token <TOKEN>             Bearer token (requires --server)
      --server <SERVER>           API server URL (required with --token)
      --as-user <USER>            Impersonate a user
      --as-group <GROUP>          Impersonate a group
      --pivot                     Recursive identity pivot via SA secrets and TokenRequest
      --pivot-depth <N>           Maximum pivot depth [default: 3]
  -o, --output <OUTPUT>           Output format [default: terminal] [values: terminal, json]
  -w, --write <WRITE>             Write JSON results to file
  -s, --severity <SEVERITY>       Minimum severity [default: low] [values: critical, high, medium, low, info]
      --unconventional-only       Show only unconventional RBAC abuses
      --chains-only               Show only attack chains
  -h, --help                      Print help
  -V, --version                   Print version

Authentifizierung

kube-reaper probiert diese Authentifizierungsmethoden in dieser Reihenfolge aus:

1. --token + --server - Direkter Bearer-Token. Verwendung mit einem gestohlenen SA-Token oder JWT. Akzeptiert selbstsignierte Zertifikate automatisch.
2. --kubeconfig / -k - Explizite kubeconfig-Datei. Liest auch die Umgebungsvariable KUBECONFIG.
3. Standard - In-Cluster-Konfiguration (innerhalb eines Pods), dann ~/.kube/config.

--as-user und --as-group fügen jeder Authentifizierungsmethode Impersonation-Header hinzu. Deine Identität muss das Verb impersonate besitzen, damit dies funktioniert.

Identitäts-Pivot

Das Flag --pivot aktiviert rekursives Identitäts-Pivoting. Diese Funktion entdeckt transitive Angriffspfade, indem sie durch Service-Account-Anmeldedaten pivotiert.

Funktionsweise

1. kube-reaper analysiert die Berechtigungen der aktuellen Identität pro Namespace.
2. Für jeden Namespace, in dem die Identität Secrets lesen kann, liest es SA-Token-Secrets (Typ kubernetes.io/service-account-token) und extrahiert den Token.
3. Für jeden Namespace, in dem die Identität serviceaccounts/token ohne Einschränkungen des Ressourcennamens erstellen kann, prägt es kurzlebige Token über die TokenRequest-API.
4. Für jeden entdeckten Token authentifiziert es sich als dieser Service Account und zählt dessen Berechtigungen über alle bekannten Namespaces auf.
5. Wenn die pivotierte Identität ebenfalls Secrets lesen oder Token prägen kann, wiederholt sich der Prozess bis zu --pivot-depth (Standard: 3).

Der Scan verwendet BFS-Traversierung, um die kürzesten Pivot-Pfade zuerst zu finden. Er stoppt bei 50 Identitäten, um unkontrollierte Scans zu verhindern.

Was in der Ausgabe erscheint

Jede pivotierte Identität zeigt:

• Schweregrad basierend auf ihren gefährlichen Berechtigungen
• Pivot-Methode (SecretToken oder TokenRequest) und Quelle
• Gefährliche Berechtigungen, die auf dieser Identität gefunden wurden
• Weitere Pivot-Fähigkeit (in welchen Namespaces sie Secrets lesen oder Token prägen kann)

Berechtigungsprüfungen

Der Pivot-Scanner wendet diese Schutzmaßnahmen an, um Fehlalarme zu verhindern:

• API-Gruppen-Scoping: Nur Regeln in der Core-API-Gruppe (oder apiGroups: ["*"]) zählen für Secret-Lese- und Token-Erstellungsprüfungen. Regeln in Nicht-Core-Gruppen (z. B. custom.metrics.k8s.io) stimmen nicht überein.
• Ressourcennamen-Einschränkungen: Regeln mit gesetztem resourceNames zählen nicht für die Token-Erstellung. Eine Regel, die die Token-Erstellung für einen benannten Service Account erlaubt, ist nicht dasselbe wie uneingeschränkte Token-Erstellung.
• Verb-Wildcard-Abgleich: Das Muster „Wildcard on All Resources" erfordert verbs: ["*"], nicht nur irgendein Verb auf resources: ["*"].

Ausgabeabschnitte

Die Terminal-Ausgabe zeigt diese Abschnitte (jeder erscheint nur, wenn er Ergebnisse enthält):