kube-reaper

Mappatore di percorsi di attacco RBAC per Kubernetes. Trova cosa può fare la tua identità, segnala permessi pericolosi e li concatena in percorsi multi-step verso la compromissione del cluster.

Progettato per red teamer e penetration tester.

Cosa fa

kube-reaper analizza un cluster Kubernetes da qualsiasi identità (utente, service account, gruppo) e produce:

• 55 pattern di permessi pericolosi con valutazioni di gravità e istruzioni di attacco
• 18 tipi di catene di attacco che collegano i permessi in percorsi di escalation multi-step
• Pivot ricorsivo delle identità che legge i secret dei token SA e conia token per mappare l'accesso transitivo tra le identità
• Mappatura del pivot dei pod che collega l'accesso exec, i pod in esecuzione e i permessi dei service account
• Rilevamento di pod pericolosi che segnala container privilegiati, mount dell'host, socket di runtime e secret esposti
• Enumerazione del grafo RBAC che mappa tutte le identità ai loro permessi effettivi e segnala target di pivot con privilegi eccessivi
• 31 pattern di minaccia CRD per ArgoCD, Flux, Istio, cert-manager, Kyverno, Gatekeeper, Tekton, Crossplane, Calico e altri
• Triage dei secret che classifica i secret accessibili per tipo (token SA, credenziali di registry, certificati TLS, chiavi SSH, opachi)
• Analisi del contesto dei pod per vettori di container escape, capability Linux, IMDS cloud e interfacce di rete
• Modalità senza kubectl per controlli solo locali quando l'API server non è raggiungibile da un pod

Installazione

Richiede una toolchain Rust (rustup + stable).

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

Il binario si trova in target/release/kube-reaper.

Binario statico (consigliato per il deployment)

Una build musl produce un binario completamente statico senza dipendenze. Funziona su qualsiasi sistema Linux x86_64.

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

Il binario si trova in 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

Avvio rapido

# 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

Riferimento CLI

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

Autenticazione

kube-reaper prova questi metodi di autenticazione in ordine:

1. --token + --server - Bearer token diretto. Da usare con un token SA rubato o un JWT. Accetta automaticamente certificati self-signed.
2. --kubeconfig / -k - File kubeconfig esplicito. Legge anche la variabile d'ambiente KUBECONFIG.
3. Default - Config in-cluster (all'interno di un pod), poi ~/.kube/config.

--as-user e --as-group aggiungono header di impersonificazione a qualsiasi metodo di autenticazione. La tua identità deve avere il verbo impersonate perché funzioni.

Pivot delle identità

Il flag --pivot abilita il pivot ricorsivo delle identità. Questa funzionalità scopre percorsi di attacco transitivi effettuando pivot attraverso le credenziali dei service account.

Come funziona

1. kube-reaper analizza i permessi dell'identità corrente per namespace.
2. Per ogni namespace in cui l'identità può leggere i secret, legge i secret dei token SA (tipo kubernetes.io/service-account-token) ed estrae il token.
3. Per ogni namespace in cui l'identità può creare serviceaccounts/token senza restrizioni sul nome della risorsa, conia token a breve scadenza tramite l'API TokenRequest.
4. Per ogni token scoperto, si autentica come quel service account ed enumera i suoi permessi su tutti i namespace noti.
5. Se l'identità ottenuta tramite pivot può anche leggere secret o coniare token, il processo si ripete fino a --pivot-depth (default: 3).

La scansione usa una traversata BFS per trovare prima i percorsi di pivot più brevi. Si ferma a 50 identità per prevenire scansioni incontrollate.

Cosa appare nell'output

Ogni identità ottenuta tramite pivot mostra:

• Gravità basata sui suoi permessi pericolosi
• Metodo di pivot (SecretToken o TokenRequest) e origine
• Permessi pericolosi trovati su quell'identità
• Capacità di ulteriore pivot (in quali namespace può leggere secret o coniare token)

Controlli dei permessi

Lo scanner di pivot applica queste protezioni per prevenire falsi positivi:

• Scoping del gruppo API: Solo le regole nel gruppo API core (o apiGroups: ["*"]) contano per i controlli di lettura dei secret e creazione di token. Le regole in gruppi non-core (es. custom.metrics.k8s.io) non corrispondono.
• Restrizioni sul nome della risorsa: Le regole con resourceNames impostato non contano per la creazione di token. Una regola che permette la creazione di token per un service account specifico non equivale alla creazione di token senza restrizioni.
• Corrispondenza wildcard dei verbi: Il pattern "Wildcard on All Resources" richiede verbs: ["*"], non un verbo qualsiasi su resources: ["*"].

Sezioni dell'output

L'output del terminale mostra queste sezioni (ognuna appare solo se ha risultati):