--- title: "Sua 'feature' ou minha falha? Vulnerabilidade no Kubernetes permite RCE e a equipe diz que 'é assim mesmo'" author: "Ignácio Afonso" date: "2026-01-29 08:13:00-03" category: "Segurança & Privacidade" url: "http://desbugados.scale.press/portal/desbugados/post/2026/01/29/sua-feature-ou-minha-falha-vulnerabilidade-no-kubernetes-permite-rce-e-a-equipe-diz-que-e-assim-mesmo/md" --- # Sua 'Feature', Minha Falha: Vulnerabilidade no Kubernetes Permite Invasão e a Equipe Diz 'Funciona Assim Mesmo' Imagine o seguinte cenário: você está configurando o monitoramento do seu cluster Kubernetes, uma tarefa essencial para manter tudo funcionando. Você concede uma permissão que parece inofensiva, a nodes/proxy GET, a uma ferramenta de telemetria. Afinal, 'GET' significa ler, certo? O que poderia dar errado? Acontece que, neste caso, você pode ter acabado de entregar a chave mestra do seu castelo digital. E o mais bizarro: os arquitetos do castelo dizem que a fechadura foi projetada exatamente assim. Recentemente, o pesquisador de segurança Graham Helton revelou uma vulnerabilidade que permite que essa permissão de 'leitura' seja usada para execução remota de código (RCE), abrindo caminho para o comprometimento total de um cluster. A resposta oficial da equipe do Kubernetes foi, em resumo, que isso 'funciona como pretendido'. Este artigo vai desbugar essa aparente contradição, explicando a falha, a lógica por trás da resposta e, o mais importante, o que você precisa fazer para se proteger. ## O Que é Essa Tal de 'nodes/proxy'? Uma Viagem no Tempo do Kubernetes Para entender o problema, precisamos fazer uma pequena escavação arqueológica na arquitetura do Kubernetes. O recurso nodes/proxy é um artefato poderoso. Ele funciona como um portão de acesso direto à API do Kubelet — o agente que roda em cada nó e é responsável por gerenciar os pods. Ferramentas de monitoramento, como Prometheus e Datadog, usam essa permissão para coletar métricas e logs, essencialmente para 'ler' o estado de saúde do sistema. Em um mundo ideal, permissões de leitura (GET) e permissões de escrita ou execução (CREATE, POST) são universos separados. Você não espera que a chave da caixa de correio também abra a porta do cofre. Mas é aqui que as coisas ficam interessantes. ## O Bug: Como um 'GET' vira um 'EXECUTE' A vulnerabilidade não está na permissão em si, mas em como o Kubelet a interpreta quando a comunicação acontece via WebSockets. Pense assim: para entrar em um prédio seguro, você mostra sua identidade na portaria. O sistema verifica que você tem uma permissão de 'visitante' (GET) e libera a catraca. O problema é que, uma vez lá dentro, essa mesma permissão te dá acesso à sala de controle, porque o sistema só fez a checagem na entrada. É isso que acontece aqui. Um cliente que deseja executar um comando em um pod (uma ação que deveria exigir a permissão CREATE) pode iniciar a comunicação usando o protocolo WebSocket. Acontece que o 'aperto de mãos' inicial de uma conexão WebSocket é, por padrão, uma requisição HTTP GET. O Kubelet vê essa requisição inicial, verifica que a conta de serviço tem a permissão nodes/proxy GET e diz: 'Pode entrar!'. Uma vez que a conexão é estabelecida, o sistema nunca mais verifica se a operação seguinte — a execução de um comando — deveria exigir uma permissão mais elevada. O atacante, então, tem um canal aberto para rodar o que quiser. ## 'Funciona Assim Mesmo': Desbugando a Resposta Oficial A decisão de classificar isso como 'comportamento intencional' soa absurda, mas há uma lógica de engenharia (ainda que questionável) por trás dela. Do ponto de vista de quem construiu o sistema há muito tempo, mudar esse comportamento fundamental seria como reformar a fundação de um arranha-céu em uso. A equipe do Kubernetes argumenta que criar uma lógica de dupla autorização seria 'frágil e arquitetonicamente incorreta'. A solução proposta por eles não é consertar a fechadura antiga, mas incentivar todos a usarem uma nova, mais segura: o **KEP-2862**. Este é um novo modelo de autorização mais granular, que cria permissões específicas (como nodes/metrics, nodes/logs) para que as ferramentas de monitoramento não precisem mais da chave mestra nodes/proxy. É a versão do Kubernetes para 'não mexe em time que tá ganhando', mesmo que o time esteja jogando com uma bola de boliche. Pelo menos ela é robusta, não é mesmo? ## E Daí? O Impacto Real no seu Cluster Ok, entendemos a falha e a polêmica. Mas qual o risco prático? A resposta é: **gigantesco**. Um atacante que explore essa vulnerabilidade pode: **Executar comandos em qualquer pod:** Incluindo pods de sistema com altos privilégios.**Escalar privilégios:** Obter acesso root no nó.**Roubar segredos e tokens:** Acessar credenciais e informações sensíveis de outras aplicações.**Comprometer o cluster inteiro:** A partir de um pod, o atacante pode se mover lateralmente e tomar controle de todo o ambiente.**Agir sem deixar rastros:** Comandos executados diretamente na API do Kubelet não são registrados pela política de auditoria padrão do Kubernetes.## Sua Caixa de Ferramentas Anti-Bug A boa notícia é que, agora que o 'bug' foi desbugado, você pode se proteger. A responsabilidade, por enquanto, é sua. Aqui está uma lista de ações práticas para fortalecer seu cluster: **Audite suas permissões AGORA:** Verifique quais contas de serviço, usuários e grupos têm a permissão nodes/proxy com o verbo GET. Use scripts para automatizar essa busca e questione a necessidade de cada uma.**Restrinja o acesso de rede:** Se possível, implemente políticas de rede (Network Policies) para bloquear o acesso à porta do Kubelet (10250/tcp) a partir de pods que não precisam absolutamente se comunicar com ela.**Planeje a migração para o KEP-2862:** Embora ainda não esteja em disponibilidade geral em todos os provedores, comece a estudar o KEP-2862. Verifique se suas ferramentas de monitoramento já oferecem suporte e planeje a migração assim que for viável.**Isole suas cargas de trabalho:** Adote o princípio do menor privilégio em todos os níveis. Use namespaces, políticas de rede e outras ferramentas para limitar o 'raio de explosão' caso um componente seja comprometido.A tecnologia, como a arqueologia, está cheia de artefatos poderosos e por vezes perigosos, criados em um contexto diferente. Agora que você conhece a história por trás do nodes/proxy, a ferramenta está em suas mãos para garantir que seu legado digital não se transforme em ruínas.