O que Auditoria RBAC de Cluster Kubernetes faz?
Quando Usar
- Ao realizar avaliações de segurança de clusters Kubernetes (EKS, GKE, AKS ou auto-gerenciados)
- Ao validar que as políticas RBAC impõem o menor privilégio para usuários e contas de serviço
- Ao investigar possíveis movimentações laterais ou escalonamento de privilégios dentro de um cluster Kubernetes
- Quando auditorias de conformidade exigem documentação de controles de acesso e permissões
- Ao integrar novas equipes a um cluster compartilhado e definir políticas RBAC apropriadas
Não use para auditoria de políticas de rede (use ferramentas de política de rede Cilium ou Calico), para varredura de imagens de contêiner (use Trivy ou Grype) ou para monitoramento de segurança em tempo de execução (use Falco ou Sysdig Secure).
Pré-requisitos
- kubectl configurado com permissões de leitura de cluster-admin ou equivalentes no cluster alvo
- rbac-tool instalado (
kubectl krew install rbac-toolou binário do GitHub) - KubiScan instalado (
pip install kubiscan) - Kubeaudit instalado (
brew install kubeauditou a partir de releases do GitHub) - Acesso aos logs de auditoria do cluster para correlacionar descobertas RBAC com acessos reais à API
Fluxo de Trabalho
Passo 1: Enumerar ClusterRoles e Roles com Permissões Perigosas
Identifique roles com permissões coringa, acesso a secrets, execução em pods ou capacidades de escalonamento.
# Listar todos os ClusterRoles com acesso a verbos coringa
kubectl get clusterroles -o json | python3 -c "
import json, sys
data = json.load(sys.stdin)
for role in data['items']:
name = role['metadata']['name']
for rule in role.get('rules', []):
verbs = rule.get('verbs', [])
resources = rule.get('resources', [])
if '*' in verbs or '*' in resources:
print(f'ClusterRole: {name}')
print(f' Verbs: {verbs}')
print(f' Resources: {resources}')
print(f' API Groups: {rule.get(\"apiGroups\", [])}')
print()
"
# Encontrar roles que podem ler secrets
kubectl get clusterroles -o json | python3 -c "
import json, sys
data = json.load(sys.stdin)
for role in data['items']:
name = role['metadata']['name']
for rule in role.get('rules', []):
resources = rule.get('resources', [])
verbs = rule.get('verbs', [])
if ('secrets' in resources or '*' in resources) and ('get' in verbs or 'list' in verbs or '*' in verbs):
if not name.startswith('system:'):
print(f'ClusterRole: {name} -> pode acessar secrets (verbs: {verbs})')
"
# Encontrar roles com permissão pod/exec (risco de escape de contêiner)
kubectl get clusterroles -o json | python3 -c "
import json, sys
data = json.load(sys.stdin)
for role in data['items']:
name = role['metadata']['name']
for rule in role.get('rules', []):
resources = rule.get('resources', [])
if 'pods/exec' in resources or 'pods/*' in resources:
print(f'ClusterRole: {name} -> tem acesso a pods/exec')
"
Passo 2: Auditar ClusterRoleBindings e RoleBindings
Revise os bindings para identificar quem tem acesso elevado e detectar atribuições de grupos excessivamente amplas.
# Listar todos os ClusterRoleBindings com os sujeitos
kubectl get clusterrolebindings -o json | python3 -c "
import json, sys
data = json.load(sys.stdin)
for binding in data['items']:
name = binding['metadata']['name']
role = binding['roleRef']['name']
subjects = binding.get('subjects', [])
for subject in subjects:
kind = subject.get('kind', '')
subj_name = subject.get('name', '')
ns = subject.get('namespace', 'cluster-wide')
print(f'{name} -> Role: {role} | {kind}: {subj_name} ({ns})')
" | sort
# Encontrar bindings para cluster-admin
kubectl get clusterrolebindings -o json | python3 -c "
import json, sys
data = json.load(sys.stdin)
for binding in data['items']:
if binding['roleRef']['name'] == 'cluster-admin':
print(f\"Binding: {binding['metadata']['name']}\")
for subject in binding.get('subjects', []):
print(f\" {subject.get('kind')}: {subject.get('name')} (ns: {subject.get('namespace', 'N/A')})\")
"
# Encontrar bindings que concedem acesso a todos os usuários autenticados
kubectl get clusterrolebindings -o json | python3 -c "
import json, sys
data = json.load(sys.stdin)
for binding in data['items']:
for subject in binding.get('subjects', []):
if subject.get('name') in ['system:authenticated', 'system:unauthenticated']:
print(f\"AVISO: {binding['metadata']['name']} concede {binding['roleRef']['name']} a {subject['name']}\")
"
Passo 3: Escanear com rbac-tool para Análise Abrangente
Use rbac-tool para análise automatizada de RBAC, incluindo consultas who-can e geração de políticas.
# Quem pode obter secrets em todos os namespaces
kubectl rbac-tool who-can get secrets
# Quem pode criar pods (potencial para escape de contêiner)
kubectl rbac-tool who-can create pods
# Quem pode executar comandos em pods
kubectl rbac-tool who-can create pods/exec
# Quem pode escalonar privilégios (verbos bind/escalate)
kubectl rbac-tool who-can bind clusterroles
kubectl rbac-tool who-can escalate clusterroles
# Gerar relatório de política RBAC
kubectl rbac-tool analysis
# Visualizar relacionamentos RBAC
kubectl rbac-tool viz --outformat dot > rbac-graph.dot
dot -Tpng rbac-graph.dot -o rbac-graph.png
Passo 4: Executar KubiScan para Detecção de Permissões Arriscadas
Use o KubiScan para identificar automaticamente contas de serviço, pods e configurações RBAC arriscados.
# Executar KubiScan para encontrar Roles arriscadas
python3 -m kubiscan -rroles # Listar Roles arriscadas
python3 -m kubiscan -rcr # Listar ClusterRoles arriscadas
python3 -m kubiscan -rrb # Listar RoleBindings arriscadas
python3 -m kubiscan -rcrb # Listar ClusterRoleBindings arriscadas
# Encontrar contas de serviço arriscadas
python3 -m kubiscan -rs # Contas de serviço arriscadas
# Encontrar pods executando com contas de serviço arriscadas
python3 -m kubiscan -rp # Pods arriscados
# Verificar caminhos de escalonamento de privilégios
python3 -m kubiscan -pe # Vetores de escalonamento de privilégios
# Gerar relatório completo
python3 -m kubiscan -a # Todas as verificações
Passo 5: Auditar Montagem e Uso de Tokens de Contas de Serviço
Verifique montagens desnecessárias de tokens de contas de serviço que poderiam permitir movimentação lateral a partir de pods comprometidos.
# Encontrar pods com tokens de contas de serviço montados automaticamente
kubectl get pods --all-namespaces -o json | python3 -c "
import json, sys
data = json.load(sys.stdin)
for pod in data['items']:
name = pod['metadata']['name']
ns = pod['metadata']['namespace']
sa = pod['spec'].get('serviceAccountName', 'default')
automount = pod['spec'].get('automountServiceAccountToken', True)
if automount and sa != 'default':
print(f'{ns}/{name} -> SA: {sa} (token montado automaticamente)')
"
# Encontrar contas de serviço com segredos de token não padrão
kubectl get serviceaccounts --all-namespaces -o json | python3 -c "
import json, sys
data = json.load(sys.stdin)
for sa in data['items']:
name = sa['metadata']['name']
ns = sa['metadata']['namespace']
secrets = sa.get('secrets', [])
if name != 'default' and len(secrets) > 0:
print(f'{ns}/{name}: {len(secrets)} segredo(s) vinculado(s)')
"
# Verificar pods executando como privilegiados ou com acesso ao host
kubectl get pods --all-namespaces -o json | python3 -c "
import json, sys
data = json.load(sys.stdin)
for pod in data['items']:
name = pod['metadata']['name']
ns = pod['metadata']['namespace']
for container in pod['spec'].get('containers', []):
sc = container.get('securityContext', {})
if sc.get('privileged', False) or sc.get('runAsUser', 1) == 0:
print(f'RISCO: {ns}/{name}/{container[\"name\"]} - privileged={sc.get(\"privileged\",False)} runAsRoot={sc.get(\"runAsUser\",\"não definido\")==0}')
"
Passo 6: Executar Kubeaudit para Validação de RBAC e Políticas de Segurança
Execute o Kubeaudit para verificações abrangentes de segurança, incluindo descobertas relacionadas a RBAC.
# Executar todas as verificações do kubeaudit
kubeaudit all --kubeconfig ~/.kube/config
# Executar verificações específicas relacionadas a RBAC
kubeaudit privesc # Verificar allowPrivilegeEscalation
kubeaudit rootfs # Verificar readOnlyRootFilesystem
kubeaudit nonroot # Verificar runAsNonRoot
kubeaudit capabilities # Verificar capabilities perigosas
# Gerar saída em JSON para processamento
kubeaudit all --kubeconfig ~/.kube/config -f json > kubeaudit-results.json
Conceitos-Chave
| Termo | Definição |
|---|---|
| RBAC | Controle de Acesso Baseado em Funções no Kubernetes, um método para regular o acesso a recursos do cluster com base nas funções de usuários individuais ou contas de serviço |
| ClusterRole | Definição de função em nível de cluster que especifica permissões (verbos sobre recursos) aplicáveis a todos os namespaces |
| ClusterRoleBinding | Associa uma ClusterRole a sujeitos (usuários, grupos, contas de serviço) no escopo do cluster |
| Conta de Serviço | Identidade associada a pods para autenticação no servidor da API do Kubernetes, montada automaticamente a menos que desabilitada |
| automountServiceAccountToken | Campo do spec do pod que controla se o token da conta de serviço é montado automaticamente no sistema de arquivos do pod |
| Escalonamento de Privilégios | Verbos RBAC (bind, escalate, impersonate) que permitem a um usuário conceder a si mesmo ou a outros permissões elevadas |
Ferramentas e Sistemas
- kubectl: CLI principal para consultar recursos RBAC do Kubernetes (roles, bindings, contas de serviço)
- rbac-tool: Plugin kubectl para análise RBAC, incluindo consultas who-can, visualização e geração de políticas
- KubiScan: Ferramenta Python para escanear RBAC do Kubernetes em busca de permissões arriscadas e caminhos de escalonamento de privilégios
- Kubeaudit: Ferramenta de auditoria de segurança que verifica pods e workloads em busca de antipadrões de segurança, incluindo problemas RBAC
- rakkess: Plugin kubectl que exibe a matriz de acesso do usuário atual em todos os tipos de recursos
Cenários Comuns
Cenário: Auditando um Cluster EKS Compartilhado por Múltiplas Equipes de Desenvolvimento
Contexto: Um cluster EKS compartilhado atende quatro equipes de desenvolvimento. O RBAC foi configurado durante a configuração inicial, mas não foi revisado em 12 meses. As equipes relatam conseguir acessar os namespaces de outras equipes.
Abordagem:
- Listar todos os ClusterRoleBindings para identificar bindings que concedem acesso amplo a usuários autenticados
- Executar
kubectl rbac-tool who-can get secretspara encontrar sujeitos que podem ler secrets em todos os namespaces - Descobrir que um ClusterRoleBinding concede
editasystem:authenticated, dando a todos os usuários acesso de escrita em todo o cluster - Executar KubiScan para identificar contas de serviço com permissões arriscadas e pods executando com contas de serviço elevadas
- Substituir o ClusterRoleBinding por RoleBindings com escopo de namespace para cada equipe
- Desabilitar automountServiceAccountToken para workloads que não precisam de acesso à API
- Criar uma NetworkPolicy para isolar o tráfego entre namespaces das equipes
Armadilhas: Remover ClusterRoleBindings pode quebrar pipelines de CI/CD e operadores que dependem de acesso em todo o cluster. Sempre audite quais workloads usam os bindings antes de removê-los. O EKS mapeia funções IAM para grupos do Kubernetes através do ConfigMap aws-auth, portanto, as alterações RBAC devem ser coordenadas com os mapeamentos de funções IAM.
Formato de Saída
Relatório de Auditoria RBAC do Kubernetes
============================================
Cluster: production-eks (EKS 1.28)
Data da Auditoria: 2026-02-23
Namespaces: 12
INVENTÁRIO RBAC:
ClusterRoles: 48 (18 personalizadas, 30 de sistema)
ClusterRoleBindings: 32 (12 personalizadas, 20 de sistema)
Roles (com escopo de namespace): 24
RoleBindings (com escopo de namespace): 36
Contas de Serviço: 67
ACHADOS CRÍTICOS:
[RBAC-001] ClusterRoleBinding Concede edit a system:authenticated
Binding: authenticated-edit
Efeito: TODOS os usuários autenticados têm acesso de edição em TODOS os namespaces
Risco: Qualquer usuário pode modificar recursos em qualquer namespace
Remediação: Substituir por RoleBindings com escopo de namespace por equipe
[RBAC-002] ClusterRole Personalizada com Permissões Coringa
ClusterRole: developer-admin
Regras: verbs=["*"], resources=["*"], apiGroups=["*"]
Bindings: 4 usuários via developer-admin-binding
Risco: Equivalente a cluster-admin sem o nome
Remediação: Escopo para recursos e verbos específicos necessários
SUMÁRIO:
Principais com cluster-admin: 6 (recomendado: <= 3)
Roles com permissões coringa: 4
Contas de serviço com acesso a secrets: 12
Pods com tokens montados automaticamente: 45 / 67
Contêineres privilegiados: 8