Kubernetes v1.36: Autorização Granular Chega em GA e Acaba de Vez com o Risco de RCE por WebSocket

Um único poder mal concedido — a permissão nodes/proxy — manteve por anos a porta dos fundos do Kubernetes escancarada. Bastava um agente de monitoramento comprometido para transformar leitura de métricas em execução remota de comandos arbitrários em cada nó do cluster. A versão 1.36 acaba de trancar essa porta. E para sempre.

O que mudou — e por que isso redefine a superfície de ataque do kubelet

A feature KubeletFineGrainedAuthz chegou ao estágio GA na v1.36 com a feature gate ativada por padrão. Não é um patch cosmético. É uma reescrita completa do modelo de autorização da API do kubelet, substituindo uma permissão monolítica e perigosa por um sistema de subrecursos individuais com controle fino de acesso.

Até ontem, cargas de trabalho legítimas — Prometheus, Datadog, Grafana Agent — precisavam de nodes/proxy para acessar métricas, logs e estatísticas. Essa permissão, porém, era muito mais do que parecia: funcionava como um passe universal para toda a API do kubelet, incluindo endpoints críticos como /exec, /attach e /portforward.

Era o equivalente a pedir uma chave para abrir uma porta específica e receber um molho com acesso a todas as fechaduras do prédio.

De monolítico a granular: o que entra e o que sai de cena

A migração introduz subrecursos dedicados para cada necessidade real de acesso ao kubelet. Veja como fica o novo mapa de permissões:

Mecanismo de transição suave: O kubelet agora realiza uma verificação dupla. Primeiro consulta se há permissão no subrecurso fino. Se falhar, recorre ao nodes/proxy como compatibilidade retroativa. Isso impede quebras abruptas durante a migração, mas não elimina o risco enquanto o modelo antigo coexistir.

Por que isso é um marco de segurança — e não apenas uma melhoria incremental

O superpoder que não deveria existir

nodes/proxy era, na prática, um superpoder no esquema RBAC. Mesmo concedida apenas para leitura (método GET), autorizava acesso a endpoints como /exec, que estabelecem conexão WebSocket para execução interativa de comandos em qualquer contêiner do nó. A assimetria era brutal.

Um atacante que comprometesse um DaemonSet de monitoramento — algo rodando em todos os nós, com nodes/proxy — poderia:

• Executar kubectl exec arbitrário em qualquer pod, sem restrições.
• Obter shells interativos em contêineres de produção.
• Exfiltrar dados sensíveis, modificar configurações em runtime ou plantar backdoors persistentes.

Menor privilégio de verdade

Com a autorização fina, um agente do Prometheus recebe exclusivamente nodes/metrics e nodes/stats. Ele nunca toca em endpoints de execução remota porque simplesmente não tem permissão para isso. O endpoint /exec continua acessível, mas apenas para componentes que explicitamente o requisitarem, sob controle de método rigoroso.

O que a v1.36 entrega, na essência, é a aplicação definitiva do princípio do menor privilégio à superfície de ataque mais crítica de qualquer cluster Kubernetes: a API do kubelet.

Implicações técnicas imediatas

Para operadores de cluster

A mudança exige ação coordenada. Todos os ClusterRole e Role que hoje concedem nodes/proxy para observabilidade precisam ser revisados e atualizados para os novos subrecursos.

Para verificar se a funcionalidade está ativa no kubelet:

curl -s <kubelet-metrics-endpoint> | grep kubernetes_feature_enabled{KubeletFineGrainedAuthz}

O valor 1 confirma que o novo modo está operando.

Atenção: Enquanto o API server e o kubelet não estiverem ambos na v1.36, o fallback mantém nodes/proxy funcional. A segurança plena só chega com o upgrade completo dos dois componentes e a migração integral dos RBACs.

Para provedores de observabilidade

Prometheus, Datadog, New Relic, Grafana e todo o ecossistema precisarão atualizar charts Helm, manifests padrão e documentações para consumir nodes/metrics e nodes/stats, eliminando progressivamente a dependência de nodes/proxy.

Para operadores que já praticam RBAC minimalista em Deployments e DaemonSets, a transição será amplamente transparente. Já workloads projetados com nodes/proxy como canivete suíço exigirão intervenção manual criteriosa.

Pressão de mercado e o fim do nodes/proxy como zona de conforto

A promoção ao estágio GA cria ondas que vão além da esfera técnica:

• Admission controllers como OPA/Gatekeeper e Kyverno tendem a bloquear a concessão de nodes/proxy em namespaces não críticos, transformando a recomendação de segurança em imposição de compliance.
• Helm charts legados — milhares ainda utilizam nodes/proxy por inércia — precisarão ser atualizados. A cauda longa da adoção deve se estender por meses.
• A comunidade já sinaliza que nodes/proxy pode ser formalmente depreciado para observabilidade nas próximas versões, possivelmente a partir da v1.38.

Quem antecipar a migração agora não apenas ganha em segurança — evita a correria reativa quando o aviso de depreciação oficial chegar.

Riscos e limitações que exigem atenção

O novo modelo é um avanço inegável, mas não é mágica. Alguns pontos merecem vigilância:

• Migração manual: o fallback evita quebras, mas a adoção real dos subrecursos depende de ação ativa. Sem intervenção, clusters permanecem no modo de compatibilidade com a vulnerabilidade intacta.
• Ambientes heterogêneos: nós com versões antigas do kubelet ainda dependem de nodes/proxy, mantendo risco de RCE em parte da infraestrutura.
• Complexidade de depuração: mais subrecursos significam mais regras RBAC para gerenciar, auditar e depurar. Ferramentas como kubectl auth can-i e análise de audit logs se tornam ainda mais essenciais.
• Tempo de adoção do ecossistema: inúmeros charts, operadores e DaemonSets de terceiros levarão meses para serem atualizados completamente.

O que está em jogo agora

A v1.36 representa um ponto de inflexão na maturidade de segurança do Kubernetes. A eliminação do nodes/proxy como permissão catch-all fecha uma brecha que existia desde o início do projeto — quando conveniência operacional falava mais alto que rigor de segurança.

A tendência consolidada é inequívoca: RBAC granular, observabilidade segura e compliance automatizado. Ferramentas de policy-as-code, plataformas de Zero Trust para Kubernetes e admission controllers passarão a bloquear automaticamente qualquer ClusterRole que conceda nodes/proxy sem justificativa técnica documentada.

O futuro da segurança em Kubernetes é finamente granulado — e a v1.36 acaba de entregar a chave definitiva para essa nova era. Quem não migrar estará, literalmente, mantendo uma porta aberta para comandos arbitrários em todo o cluster. Num cenário de ameaças cada vez mais sofisticadas, portas abertas raramente passam despercebidas por muito tempo.