kube-reaper

Mapeador de caminhos de ataque de RBAC do Kubernetes. Ele descobre o que sua identidade pode fazer, sinaliza permissões perigosas e as encadeia em caminhos de múltiplas etapas até o comprometimento do cluster.

Feito para red teamers e testadores de penetração.

O Que Ele Faz

O kube-reaper escaneia um cluster Kubernetes a partir de qualquer identidade (usuário, service account, grupo) e produz:

• 55 padrões de permissões perigosas com classificações de severidade e instruções de ataque
• 18 tipos de cadeias de ataque que ligam permissões em caminhos de escalação de múltiplas etapas
• Pivotamento recursivo de identidade que lê secrets de token de SA e emite tokens para mapear acesso transitivo entre identidades
• Mapeamento de pivot de Pod que conecta acesso exec, pods em execução e permissões de service account
• Detecção de pods perigosos que sinaliza contêineres privilegiados, montagens de host, sockets de runtime e secrets expostos
• Enumeração de grafo RBAC que mapeia todas as identidades para suas permissões efetivas e sinaliza alvos de pivot com privilégios excessivos
• 31 padrões de ameaça de CRD para ArgoCD, Flux, Istio, cert-manager, Kyverno, Gatekeeper, Tekton, Crossplane, Calico e outros
• Triagem de secrets que classifica secrets acessíveis por tipo (tokens de SA, credenciais de registry, certificados TLS, chaves SSH, opacos)
• Análise de contexto de Pod para vetores de escape de contêiner, capacidades do Linux, IMDS de nuvem e interfaces de rede
• Modo sem kubectl para verificações apenas locais quando o servidor de API não é acessível a partir de um pod

Instalação

Requer uma toolchain Rust (rustup + stable).

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

O binário está em target/release/kube-reaper.

Binário estático (recomendado para implantação)

Uma build musl produz um binário totalmente estático sem dependências. Funciona em qualquer sistema Linux x86_64.

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

O binário está em 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

Início 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

Referência da 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

Autenticação

O kube-reaper tenta estes métodos de autenticação na seguinte ordem:

1. --token + --server - Bearer token direto. Use com um token de SA roubado ou JWT. Aceita certificados autoassinados automaticamente.
2. --kubeconfig / -k - Arquivo kubeconfig explícito. Também lê a variável de ambiente KUBECONFIG.
3. Padrão - Configuração in-cluster (dentro de um pod), depois ~/.kube/config.

--as-user e --as-group adicionam cabeçalhos de impersonation a qualquer método de autenticação. Sua identidade deve ter o verbo impersonate para que isso funcione.

Pivot de Identidade

A flag --pivot habilita o pivotamento recursivo de identidade. Esse recurso descobre caminhos de ataque transitivos ao pivotar por meio de credenciais de service account.

Como funciona

1. O kube-reaper analisa as permissões da identidade atual por namespace.
2. Para cada namespace em que a identidade pode ler secrets, ele lê secrets de token de SA (tipo kubernetes.io/service-account-token) e extrai o token.
3. Para cada namespace em que a identidade pode criar serviceaccounts/token sem restrições de nome de recurso, ele emite tokens de curta duração via API TokenRequest.
4. Para cada token descoberto, ele se autentica como aquela service account e enumera suas permissões em todos os namespaces conhecidos.
5. Se a identidade pivotada também puder ler secrets ou emitir tokens, o processo se repete até --pivot-depth (padrão: 3).

O scan usa travessia BFS para encontrar primeiro os caminhos de pivot mais curtos. Ele para em 50 identidades para evitar scans descontrolados.

O que aparece na saída

Cada identidade pivotada mostra:

• Severidade com base em suas permissões perigosas
• Método de pivot (SecretToken ou TokenRequest) e origem
• Permissões perigosas encontradas naquela identidade
• Capacidade de pivot adicional (em quais namespaces ela pode ler secrets ou emitir tokens)

Verificações de permissão

O scanner de pivot aplica estas proteções para evitar falsos positivos:

• Escopo de grupo de API: Apenas regras no grupo de API core (ou apiGroups: ["*"]) contam para verificações de leitura de secret e criação de token. Regras em grupos não-core (por exemplo, custom.metrics.k8s.io) não correspondem.
• Restrições de nome de recurso: Regras com resourceNames definido não contam para criação de token. Uma regra que permite criação de token para uma service account nomeada não é o mesmo que criação de token irrestrita.
• Correspondência de curinga de verbo: O padrão "Wildcard on All Resources" requer verbs: ["*"], não apenas qualquer verbo em resources: ["*"].

Seções de Saída

A saída do terminal mostra estas seções (cada uma aparece apenas quando tem descobertas):