Clusters Kubernetes com RBAC mal calibrado funcionam como um prédio com portas blindadas e o molde das chaves pendurado na recepção. Quem administra clusters em provedores de nuvem ou on-premises herda, com frequência, bindings antigos, contas de serviço superprivilegiadas e API servers sem política de auditoria ativa. O resultado é um caminho curto entre o comprometimento de uma única credencial e o controle total do cluster: o invasor não precisa explorar falha nova, apenas usar o que já estava liberado. A ação prioritária é objetiva e cabe em uma semana de trabalho: inventariar todos os ClusterRoleBindings, retirar membros do grupo system:masters e garantir que o kube-apiserver registre eventos de auditoria com backend e retenção definidos.
Cure a conta de administrador
A documentação oficial do projeto é categórica: qualquer usuário membro do grupo system:masters contorna todas as verificações do RBAC e mantém acesso de superusuário irrestrito. Esse acesso não pode ser revogado removendo RoleBindings ou ClusterRoleBindings, porque o grupo fica por fora do modelo de autorização por completo. Se o cluster usa webhook de autorização, membros do grupo também ficam de fora dele: as requisições nem chegam a ser enviadas para avaliação. Não existe revisão de permissão que alcance quem está nesse grupo — por definição, ele é a exceção permanente a qualquer controle.
O tratamento começa pelo inventário. Liste quem pertence ao grupo, quais certificados de cliente o embutem — a associação costuma vir gravada no campo de organização do certificado emitido pela CA do cluster — e qual processo operacional criou esses usuários. Muitas vezes a origem é legítima: recuperação de desastre, quebra-galho de migração, ferramenta de backup. Isso não muda o risco, muda apenas o dono da decisão de remediá-lo. Cada presença no grupo precisa de justificativa escrita, data de revisão e alternativa técnica.
Em seguida, substitua o uso cotidiano de cluster-admin por contas de menor privilégio com direito de impersonação. Esse recurso permite elevar temporariamente a identidade de uma operação específica sem manter credenciais onipotentes circulando em terminais, pipelines e arquivos de configuração. A regra prática para o hardening de RBAC no Kubernetes é simples: cluster-admin existe para exceção documentada, não para rotina. E a exceção precisa gerar evento de auditoria identificável, com usuário de origem e destino registrados.
Corte permissões curinga
O Kubernetes é um sistema extensível: novos tipos de objeto aparecem a cada atualização e a cada operador instalado no cluster. Uma permissão curinga — verbs: ["*"] ou resources: ["*"] — vale para tudo que existe hoje e para tudo que vier a existir no futuro. O binding aceitável quando foi criado ganha escopo silenciosamente com o tempo, sem nenhuma mudança visível na configuração. A auditoria precisa, portanto, avaliar não apenas o que a Role permite, mas o que ela passará a permitir depois do próximo upgrade do cluster ou da instalação do próximo operador.
Prefira RoleBindings a ClusterRoleBindings sempre que possível: amarrar a permissão a um namespace específico limita o raio de explosão de um token roubado a um único ambiente. Revise também os bindings do grupo system:unauthenticated — eles dão acesso a qualquer um que consiga alcançar o API server pela rede, o que em clusters mal segmentados significa qualquer workload comprometido. A revisão periódica importa tanto quanto a criação: se um invasor recriar uma conta de usuário com o mesmo nome de uma conta deletada, ele herda automaticamente os direitos antigos, o que transforma limpeza de identidades malfeita em porta de entrada.
Permissões aparentemente inofensivas também escalam. Acesso ao sub-recurso nodes/proxy parece leitura, mas expõe a API do kubelet: permite executar comandos em pods do nó e passa por fora do admission control e do log de auditoria convencional. Direito de criar pods pode virar execução de contêiner privilegiado; direito de criar objetos em quantidade pode virar negação de serviço sobre o etcd, mitigável com resource quotas por namespace. Mapeie esses vetores junto com a microsegmentação por identidade já discutida aqui no portal: a pergunta certa é qual caminho um token roubado percorre até virar controle de cluster.
Tokens de serviço sob controle
Todo pod recebe por padrão um token de conta de serviço montado automaticamente. Um invasor que comprometa um único contêiner ganha, assim, uma credencial pronta para falar com o API server, sem precisar procurar nada. A documentação recomenda desativar o automount com automountServiceAccountToken: false na conta de serviço ou no pod; workloads que realmente precisam do token continuam conseguindo montá-lo explicitamente. O objetivo é que a maioria dos pods rode sem nenhuma credencial de cluster visível para quem invadiu o processo.
Contas de serviço com permissões amplas merecem tratamento separado. Limite em quantos nós esses pods podem rodar, use taints, tolerations e antiafinidade para afastá-los de workloads expostos à internet e trate DaemonSets privilegiados como exceção auditada, nunca como padrão de frota. O raciocínio é o mesmo dos segredos no CI/CD: credencial de alto privilégio parada em ambiente compartilhado é matéria-prima de incidente, não ferramenta de rotina. A diferença é que no cluster a credencial se renova e se distribui sozinha.
Ative a auditoria do API server
Endurecer permissões sem registrar o que acontece é trocar a fechadura e desligar a câmera. O Kubernetes gera eventos de auditoria dentro do kube-apiserver, mas a gravação depende de política explícita: sem a flag --audit-policy-file, nenhum evento de auditoria é registrado. A política é um arquivo YAML com regras avaliadas em ordem, e a ausência dela não gera erro visível — o cluster simplesmente opera sem memória. Em clusters gerenciados, verifique o que o provedor expõe por padrão e complemente com a configuração que o controle nativo permitir.
Uma política equilibrada registra mudanças em pods e secrets em nível alto, watches de serviços em nível baixo e usa Metadata como regra padrão. Os níveis disponíveis — None, Metadata, Request e RequestResponse — controlam o custo de cada evento, e RequestResponse aplicado a tudo gera consumo de memória mensurável no API server. Os backends nativos são arquivo local e webhook para API externa; em ambos, defina retenção, rotação e tamanho máximo de evento, porque auditoria sem janela de retenção é evidência que expira antes de ser consultada.
Dois indicadores dizem se a auditoria está viva: a métrica apiserver_audit_event_total, com o total de eventos exportados, e apiserver_audit_error_total, com o total de eventos descartados por erro na exportação. O segundo é o que separa logs que existem de logs que servem: auditoria que falha em silêncio durante um incidente é ausência de evidência no pior momento possível. Monitore as duas métricas e trate crescimento sustentado do contador de erros como incidente de infraestrutura, com a mesma prioridade de um serviço de produção parado.
Verifique e priorize
O comando kubectl auth can-i --list executado por cada identidade responde, direto no API server, o que ela realmente pode fazer — use o resultado como evidência de auditoria em vez de confiar no que o YAML declara. Para transformar a verificação em programa contínuo, o benchmark do CIS dedica recomendações de configuração segura ao orquestrador, publicado como Kubernetes (2.0.1), com edições separadas para plataformas gerenciadas como EKS, AKS e GKE e varredura automatizável com CIS-CAT. Rode a varredura após cada mudança de versão do cluster, não uma vez por ano: os itens que hoje passam podem falhar amanhã só pela evolução da plataforma.
| Prioridade | Ação | Sinal de conclusão |
|---|---|---|
| P1 | Remover usuários de system:masters e reduzir cluster-admin ao mínimo documentado | Nenhum certificado cotidiano embute o grupo; elevações por impersonação geram evento de auditoria |
| P1 | Ativar –audit-policy-file com backend, retenção e alerta | apiserver_audit_event_total crescente e apiserver_audit_error_total estável em zero |
| P2 | Desativar automountServiceAccountToken onde não há uso | Maioria dos pods sem token de conta de serviço montado |
| P2 | Eliminar curingas em verbs e resources e trocar ClusterRoleBindings por RoleBindings | kubectl auth can-i –list sem asteriscos fora de contas do sistema |
A decisão operacional fica clara: primeiro o que dá controle total e o que prova o que aconteceu, depois o que reduz superfície cotidiana. Endurecimento de RBAC não é projeto de trimestre — é verificação contínua sobre uma base que muda sozinha a cada upgrade. Comece pelo grupo que ignora todas as regras e termine com a métrica que prova que nada se perdeu no caminho.