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:

  1. Executar comandos em qualquer pod: Incluindo pods de sistema com altos privilégios.
  2. Escalar privilégios: Obter acesso root no nó.
  3. Roubar segredos e tokens: Acessar credenciais e informações sensíveis de outras aplicações.
  4. Comprometer o cluster inteiro: A partir de um pod, o atacante pode se mover lateralmente e tomar controle de todo o ambiente.
  5. 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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.