kube-reaper

Cartographe des chemins d'attaque RBAC Kubernetes. Il découvre ce que votre identité peut faire, signale les permissions dangereuses et les enchaîne en chemins multi-étapes menant à la compromission du cluster.

Conçu pour les red teamers et les testeurs d'intrusion.

Ce qu'il fait

kube-reaper analyse un cluster Kubernetes depuis n'importe quelle identité (utilisateur, compte de service, groupe) et produit :

• 55 motifs de permissions dangereuses avec niveaux de gravité et instructions d'attaque
• 18 types de chaînes d'attaque qui relient les permissions en chemins d'escalade multi-étapes
• Pivot d'identité récursif qui lit les secrets de jetons SA et génère des jetons pour cartographier l'accès transitif entre identités
• Cartographie de pivot par pod qui relie l'accès exec, les pods en cours d'exécution et les permissions des comptes de service
• Détection de pods dangereux qui signale les conteneurs privilégiés, les montages hôtes, les sockets runtime et les secrets exposés
• Énumération du graphe RBAC qui cartographie toutes les identités vers leurs permissions effectives et signale les cibles de pivot sur-privilégiées
• 31 motifs de menaces CRD pour ArgoCD, Flux, Istio, cert-manager, Kyverno, Gatekeeper, Tekton, Crossplane, Calico, et autres
• Triage des secrets qui classe les secrets accessibles par type (jetons SA, identifiants de registre, certificats TLS, clés SSH, opaques)
• Analyse du contexte des pods pour les vecteurs d'évasion de conteneur, les capacités Linux, l'IMDS cloud et les interfaces réseau
• Mode sans kubectl pour les vérifications locales uniquement lorsque le serveur API n'est pas joignable depuis un pod

Installation

Nécessite une toolchain Rust (rustup + stable).

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

Le binaire se trouve à target/release/kube-reaper.

Binaire statique (recommandé pour le déploiement)

Une compilation musl produit un binaire entièrement statique sans dépendances. Il fonctionne sur n'importe quel système Linux x86_64.

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

Le binaire se trouve à target/x86_64-unknown-linux-musl/release/kube-reaper (~5,4 Mo).

# 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

Démarrage rapide

# 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

Référence 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

Authentification

kube-reaper essaie ces méthodes d'authentification dans l'ordre :

1. --token + --server - Jeton bearer direct. À utiliser avec un jeton SA volé ou un JWT. Accepte automatiquement les certificats auto-signés.
2. --kubeconfig / -k - Fichier kubeconfig explicite. Lit également la variable d'environnement KUBECONFIG.
3. Par défaut - Configuration in-cluster (à l'intérieur d'un pod), puis ~/.kube/config.

--as-user et --as-group ajoutent des en-têtes d'impersonation à n'importe quelle méthode d'authentification. Votre identité doit posséder le verbe impersonate pour que cela fonctionne.

Pivot d'identité

L'option --pivot active le pivot d'identité récursif. Cette fonctionnalité découvre les chemins d'attaque transitifs en pivotant à travers les identifiants de comptes de service.

Comment ça marche

1. kube-reaper analyse les permissions de l'identité actuelle par namespace.
2. Pour chaque namespace où l'identité peut lire les secrets, il lit les secrets de jetons SA (type kubernetes.io/service-account-token) et extrait le jeton.
3. Pour chaque namespace où l'identité peut créer serviceaccounts/token sans restrictions sur le nom de ressource, il génère des jetons à courte durée de vie via l'API TokenRequest.
4. Pour chaque jeton découvert, il s'authentifie en tant que ce compte de service et énumère ses permissions sur tous les namespaces connus.
5. Si l'identité pivotée peut également lire des secrets ou générer des jetons, le processus se répète jusqu'à --pivot-depth (par défaut : 3).

L'analyse utilise un parcours BFS pour trouver d'abord les chemins de pivot les plus courts. Elle s'arrête à 50 identités pour éviter les analyses incontrôlées.

Ce qui apparaît dans la sortie

Chaque identité pivotée affiche :

• Gravité basée sur ses permissions dangereuses
• Méthode de pivot (SecretToken ou TokenRequest) et source
• Permissions dangereuses trouvées sur cette identité
• Capacité de pivot supplémentaire (dans quels namespaces elle peut lire des secrets ou générer des jetons)

Vérifications de permissions

Le scanner de pivot applique ces garde-fous pour éviter les faux positifs :

• Portée du groupe API : Seules les règles du groupe API core (ou apiGroups: ["*"]) comptent pour les vérifications de lecture de secrets et de création de jetons. Les règles dans des groupes non-core (par ex., custom.metrics.k8s.io) ne correspondent pas.
• Restrictions sur le nom de ressource : Les règles avec resourceNames défini ne comptent pas pour la création de jetons. Une règle qui permet la création de jetons pour un compte de service nommé n'est pas équivalente à une création de jetons non restreinte.
• Correspondance de joker de verbe : Le motif « Wildcard on All Resources » nécessite verbs: ["*"], pas simplement n'importe quel verbe sur resources: ["*"].

Sections de sortie

La sortie terminal affiche ces sections (chacune n'apparaît que si elle contient des résultats) :