Publicado: 2026-03-04
A equipe de pesquisa de segurança em nuvem da KENSAI analisou 12.000 clusters Kubernetes de produção em empresas europeias e descobriu que 58% contêm configurações incorretas de RBAC (Role-Based Access Control) graves o suficiente para permitir movimento lateral e escalonamento de privilégios para administrador de cluster. Os cinco padrões mais perigosos — permissões curinga, abuso de conta de serviço padrão, ClusterRoleBindings excessivos, escape de namespace por meio de direitos de criação de pod e montagem de token em pods privilegiados — estão presentes na maioria das implantações. A maioria das organizações não audita as políticas RBAC após a configuração inicial.
⚡ Se um invasor comprometer qualquer pod em 58% dos clusters verificados, ele poderá escalar para administrador de cluster completo em minutos usando apenas configurações incorretas de RBAC.
A configuração incorreta mais difundida: 23% dos clusters tenha ClusterRoles personalizados com verbos curinga (*) ou recursos. As equipes copiam o cluster-admin papel como ponto de partida e esqueça de definir seu escopo. Um único pod com uma conta de serviço vinculada a essa função tem acesso irrestrito a todos os recursos em todos os namespaces: segredos, mapas de configuração, nós e o próprio servidor API.
# Dangerous: Wildcard ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: devops-tools
rules:
- apiGroups: ["*"]
resources: ["*"]
verbs: ["*"] # ← Full cluster-admin equivalent
Cada namespace do Kubernetes tem um default conta de serviço que é montada automaticamente em pods, a menos que seja explicitamente desativada. Em 41% dos clusters, a conta de serviço padrão em pelo menos um namespace recebeu permissões elevadas — geralmente porque um operador executou um rápido kubectl create rolebinding durante a depuração e nunca o limpei. Os invasores que obtiverem RCE em qualquer pod nesse namespace herdarão imediatamente essas permissões.
34% dos clusters tenha mais de 10 ClusterRoleBindings personalizados — ligações que concedem permissões em todos os namespaces. Muitos atribuem funções amplas a grupos como system:authenticated ou system:serviceaccounts, concedendo efetivamente acesso elevado a cada usuário autenticado ou a cada conta de serviço no cluster.
Usuários com create pods permissão em qualquer namespace pode montar o sistema de arquivos host, executar contêineres privilegiados ou criar pods com qualquer conta de serviço nesse namespace. Em 29% dos clusters, os desenvolvedores têm direitos de criação de pod sem a aplicação dos padrões de segurança do pod, permitindo o escape trivial do contêiner para o nó subjacente.
O Kubernetes monta tokens de conta de serviço em pods por padrão. Quando combinados com especificações de pod privilegiadas ou acesso à rede de host, os invasores podem roubar o token e autenticar no servidor API de fora do cluster. Apenas 12% dos clusters verificados são definidos automountServiceAccountToken: false em cargas de trabalho que não precisam de acesso à API.
get secrets permissão em todos os namespaces — o invasor extraiu credenciais de banco de dados, chaves de API e certificados TLS em 4 minutos.
Mais da metade dos clusters de produção do Kubernetes analisados contém pelo menos uma configuração incorreta de RBAC que poderia permitir o escalonamento de privilégios de um pod comprometido para acesso de nível de administrador de cluster.
Em testes de penetração em clusters mal configurados, o tempo médio desde o comprometimento inicial do pod até o acesso completo do administrador do cluster foi de 3,2 minutos. Ferramentas automatizadas como peirates e kubeletctl torne isso trivial.
Clusters com permissões de leitura curinga expuseram uma média de 847 segredos do Kubernetes – incluindo credenciais de banco de dados, chaves de API, certificados TLS e tokens IAM de provedor de nuvem em todos os namespaces.
A grande maioria das organizações configura o RBAC uma vez durante o provisionamento do cluster e nunca mais o revisa. As vinculações de funções se acumulam ao longo dos meses à medida que as equipes adicionam permissões para depuração, pipelines de CI/CD e monitoramento — e nunca as removem.
O módulo de segurança Kubernetes da KENSAI agora inclui análise automatizada de RBAC que mapeia cada conta de serviço, função e vinculação em seu cluster para identificar caminhos de escalonamento de privilégios. O scanner gera um gráfico visual de cadeias de permissão e destaca o caminho mais curto de qualquer carga de trabalho comprometida até o administrador do cluster.
Cada carga de trabalho deve ter sua própria conta de serviço dedicada com apenas as permissões que ele realmente precisa. Evite vincular ClusterRoles quando funções com escopo de namespace forem suficientes. Usar automountServiceAccountToken: false para pods que não precisam de acesso à API do Kubernetes, que é a maioria das cargas de trabalho de aplicativos.
Padrões de segurança de pod do Kubernetes (PSS) no restricted nível evita que os pods sejam executados como root, montem caminhos de host ou usem modo privilegiado. Aplique-os no nível do namespace usando o Pod Security Admission. Isto elimina o vetor de escape do contêiner, mesmo que as permissões do RBAC sejam excessivamente amplas.
Implementar auditorias trimestrais do RBAC. Revise todos os ClusterRoleBindings, identifique vinculações obsoletas de membros da equipe que partiram ou serviços desativados e valide se nenhuma conta de serviço tem permissões mais amplas do que as necessárias. KENSAI pode automatizar isso com detecção contínua de desvios.
kubectl get clusterroles -o json | jq '.items[] | select(.rules[]?.verbs[]? == "*")'automountServiceAccountToken: false em todas as cargas de trabalho que não precisam de acesso à APIrestricted PSS no nível do namespace para todas as cargas de trabalho de produçãokubectl get clusterrolebindings -o wide — sinalizar qualquer coisa vinculada a grupos amploskensai scan --k8s-rbac contra seu cluster para obter uma avaliação completa de risco de RBAC em menos de 60 segundos. O relatório inclui um gráfico de escalonamento de privilégios, etapas de correção específicas por descoberta e mapeamento de conformidade NIS2 para organizações sujeitas à diretiva.
*) e recursos de ClusterRoles personalizadossystem:authenticated ou system:serviceaccountsautomountServiceAccountToken: false em todos os pods que não precisam de acesso à APIrestricted nível para namespaces de produção