Em Kubernetes, pods também têm identidade. Jobs, controllers e aplicações falam com a API, acessam outros serviços e, em muitos ambientes, chegam até recursos de cloud. Quando essa identidade recebe mais permissão do que precisa, uma falha em um workload deixa de ser um problema isolado e pode virar caminho para o restante do cluster.
Service Accounts e RBAC não são detalhes de configuração. Eles definem o raio de impacto de um comprometimento.
Service Account é identidade de máquina
Kubernetes usa Service Accounts para representar processos executados dentro do cluster. Um pod pode receber um token associado a essa identidade e usá-lo para se autenticar na API.
Isso é necessário para várias funções legítimas: controllers precisam observar recursos, operadores modificam objetos, aplicações consultam ConfigMaps ou outros componentes. O problema começa quando a permissão concedida ao workload não acompanha a função real que ele exerce.
É comum encontrar permissões amplas porque “era o jeito mais rápido de fazer funcionar”. Um chart cria ClusterRole com curingas. Um time concede acesso adicional para resolver um erro. O sistema entra em produção e aquela exceção vira permanente.
Cada namespace possui uma Service Account padrão. Se o pod não especificar outra, ele pode operar associado a ela. Isso não significa automaticamente alto privilégio, mas cria um ponto que precisa ser entendido: quais permissões a conta padrão possui e o workload realmente precisa de token?
Quando não há necessidade de falar com a API do Kubernetes, montar automaticamente um token dentro do pod só acrescenta uma credencial que um atacante poderá tentar aproveitar após comprometer a aplicação.
RBAC é o que separa comprometimento de escalonamento
A pergunta mais importante em RBAC não é apenas “essa aplicação funciona?”, e sim “o que alguém conseguiria fazer se assumisse essa identidade?”.
Permissão para listar pods tem um risco. Permissão para ler Secrets tem outro. Criar pods, executar comandos, impersonar identidades, alterar RoleBindings ou criar workloads privilegiados pode abrir caminhos claros de escalonamento.
Por isso, revisar apenas a existência de RBAC não basta. É preciso entender as permissões efetivas e as combinações que criam caminhos de privilégio.
Notícias Relacionadas
- Ataque de identidade no Kubernetes expõe limite de confiança do SPIFFE/SPIRE
- Segurança em AWS e Kubernetes: onde IAM, workloads e secrets se encontram
O risco aumenta quando Kubernetes e cloud se encontram
Em ambientes EKS, GKE e AKS, workloads muitas vezes precisam acessar serviços fora do cluster: storage, filas, bancos, secrets managers ou APIs de cloud. Workload identity ajuda a reduzir segredos estáticos, o que é positivo. Mas o vínculo entre identidade do Kubernetes e identidade da nuvem precisa ser restrito.
Se uma Service Account comprometida consegue assumir um papel de cloud amplo demais, o atacante sai do cluster sem precisar explorar outra vulnerabilidade. O problema deixou de ser “Kubernetes” e passou a atravessar toda a conta de nuvem.
Um dos erros mais perigosos é conceder leitura ampla de Secrets porque a aplicação precisa de um ou dois valores. Isso transforma uma identidade comprometida em ponto de coleta de credenciais de outros serviços.
O ideal é reduzir o número de secrets disponíveis, segmentar acesso e, sempre que possível, utilizar mecanismos de identidade de workload que evitem distribuir credenciais persistentes.
Controles que reduzem o blast radius
- Service Accounts específicas por workload. Evitar compartilhar a conta padrão entre aplicações com funções diferentes.
- Menor privilégio no RBAC. Conceder verbos e recursos necessários, evitando curingas sem justificativa.
- Desabilitar automount quando não for necessário. Um pod que não fala com a API não precisa receber token por conveniência.
- Preferir tokens de curta duração. Credenciais temporárias reduzem a janela de reutilização.
- Separar identidade de cluster e cloud. O mapeamento para papéis externos deve ser específico e revisado.
- Auditar permissões efetivas. RoleBindings e ClusterRoleBindings acumulam exceções ao longo do tempo.
- Monitorar a API. Um workload que nunca cria pods e passa a fazê-lo merece atenção imediata.
Um manifesto pode parecer razoável e ainda criar risco em conjunto com outros recursos. A análise precisa considerar namespace, bindings, admission policies, capacidades do container, acesso a volumes, secrets e relações com a nuvem.
É por isso que revisões de Kubernetes funcionam melhor quando combinam configuração estática com análise de caminhos de privilégio. O que interessa é o que a identidade realmente consegue fazer depois que todas as políticas são resolvidas.
Ambientes Kubernetes mudam rápido. Times criam namespaces, instalam operators, atualizam charts e adicionam integrações. Uma revisão anual tende a encontrar um cenário muito diferente daquele que foi aprovado originalmente.
Service Accounts sem uso, roles excessivas, bindings antigos e contas ligadas a workloads que já não existem deveriam entrar em uma rotina de higiene, da mesma forma que contas de usuários inativas entram em um processo de IAM.
Em muitos incidentes de Kubernetes, a investigação começa pela rede: qual pod falou com qual serviço. Isso ajuda, mas não explica autoridade. Duas conexões idênticas podem ter significados completamente diferentes dependendo da Service Account usada e das permissões associadas.
Por isso, telemetria de identidade e rede deveriam ser correlacionadas. Saber que um pod acessou a API é útil; saber que ele fez isso com uma identidade que normalmente nunca chama aquele recurso é muito melhor. Essa combinação aproxima detecção de comportamento real do workload, em vez de olhar apenas para IP e porta.
Conclusão
Kubernetes é uma plataforma de orquestração, mas também é um sistema de identidade. Cada Service Account representa autoridade. RBAC define até onde essa autoridade vai.
O desenho mais seguro não tenta impedir todo comprometimento. Assume que algum workload pode falhar e garante que essa falha não entregue o cluster inteiro, os Secrets e a conta de cloud junto com ele.
Veja também
- Visibilidade de identidade em 2026: por que saber quem pode acessar já não é suficiente
- Gestão de Identidade no Mundo Moderno
Be the first to comment