kube-reaper

Mapeador de rutas de ataque RBAC de Kubernetes. Encuentra lo que tu identidad puede hacer, marca permisos peligrosos y los encadena en rutas de múltiples pasos hacia el compromiso del clúster.

Diseñado para equipos rojos y pentesters.

Qué hace

kube-reaper escanea un clúster de Kubernetes desde cualquier identidad (usuario, cuenta de servicio, grupo) y produce:

• 55 patrones de permisos peligrosos con clasificaciones de severidad e instrucciones de ataque
• 18 tipos de cadenas de ataque que enlazan permisos en rutas de escalada de múltiples pasos
• Pivoting recursivo de identidad que lee secretos de tokens de SA y acuña tokens para mapear el acceso transitivo entre identidades
• Mapeo de pivoting de pods que conecta el acceso exec, los pods en ejecución y los permisos de las cuentas de servicio
• Detección de pods peligrosos que marca contenedores privilegiados, montajes del host, sockets de runtime y secretos expuestos
• Enumeración del grafo RBAC que mapea todas las identidades a sus permisos efectivos y marca objetivos de pivoting con privilegios excesivos
• 31 patrones de amenazas de CRD para ArgoCD, Flux, Istio, cert-manager, Kyverno, Gatekeeper, Tekton, Crossplane, Calico y otros
• Triaje de secretos que clasifica los secretos accesibles por tipo (tokens de SA, credenciales de registro, certificados TLS, claves SSH, opacos)
• Análisis del contexto del pod para vectores de escape de contenedores, capacidades de Linux, IMDS de la nube e interfaces de red
• Modo sin kubectl para comprobaciones solo locales cuando el servidor de API no es accesible desde un pod

Instalación

Requiere una toolchain de Rust (rustup + stable).

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

El binario está en target/release/kube-reaper.

Binario estático (recomendado para despliegue)

Una compilación musl produce un binario totalmente estático sin dependencias. Funciona en cualquier sistema Linux x86_64.

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

El binario está en 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

Inicio rápido

# 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

Referencia de la 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

Autenticación

kube-reaper prueba estos métodos de autenticación en orden:

1. --token + --server - Token bearer directo. Úsalo con un token de SA robado o un JWT. Acepta certificados autofirmados automáticamente.
2. --kubeconfig / -k - Archivo kubeconfig explícito. También lee la variable de entorno KUBECONFIG.
3. Predeterminado - Configuración in-cluster (dentro de un pod), luego ~/.kube/config.

--as-user y --as-group añaden cabeceras de impersonation a cualquier método de autenticación. Tu identidad debe tener el verbo impersonate para que esto funcione.

Pivoting de identidad

El flag --pivot habilita el pivoting recursivo de identidad. Esta característica descubre rutas de ataque transitivas pivotando a través de credenciales de cuentas de servicio.

Cómo funciona

1. kube-reaper analiza los permisos de la identidad actual por namespace.
2. Para cada namespace donde la identidad puede leer secretos, lee los secretos de token de SA (tipo kubernetes.io/service-account-token) y extrae el token.
3. Para cada namespace donde la identidad puede crear serviceaccounts/token sin restricciones de nombre de recurso, acuña tokens de corta duración mediante la API TokenRequest.
4. Para cada token descubierto, se autentica como esa cuenta de servicio y enumera sus permisos en todos los namespaces conocidos.
5. Si la identidad pivotada también puede leer secretos o acuñar tokens, el proceso se repite hasta --pivot-depth (predeterminado: 3).

El escaneo usa recorrido BFS para encontrar primero las rutas de pivoting más cortas. Se detiene a las 50 identidades para evitar escaneos descontrolados.

Qué aparece en la salida

Cada identidad pivotada muestra:

• Severidad basada en sus permisos peligrosos
• Método de pivoting (SecretToken o TokenRequest) y origen
• Permisos peligrosos encontrados en esa identidad
• Capacidad de pivoting adicional (en qué namespaces puede leer secretos o acuñar tokens)

Comprobaciones de permisos

El escáner de pivoting aplica estas protecciones para evitar falsos positivos:

• Alcance del grupo de API: Solo las reglas del grupo de API core (o apiGroups: ["*"]) cuentan para las comprobaciones de lectura de secretos y creación de tokens. Las reglas en grupos no core (p. ej., custom.metrics.k8s.io) no coinciden.
• Restricciones de nombre de recurso: Las reglas con resourceNames establecido no cuentan para la creación de tokens. Una regla que permite la creación de tokens para una cuenta de servicio con nombre concreto no es lo mismo que la creación de tokens sin restricciones.
• Coincidencia de comodines de verbos: El patrón "Wildcard on All Resources" requiere verbs: ["*"], no solo cualquier verbo en resources: ["*"].

Secciones de salida

La salida de terminal muestra estas secciones (cada una aparece solo cuando tiene hallazgos):