Kubernetes v1.36: Autorização Granular da API do Kubelet atinge GA e aumenta a segurança do cluster

Com o lançamento do Kubernetes v1.36, a funcionalidade de autorização granular para a API do Kubelet (KubeletFineGrainedAuthz) atingiu o status de General Availability (GA). Esta atualização marca o fim de um modelo de permissões historicamente arriscado e encerra a necessidade de conceder o acesso excessivamente amplo nodes/proxy para tarefas de rotina, como coleta de métricas e observabilidade.

O problema da permissão nodes/proxy

Historicamente, o Kubelet utilizava um modelo de autorização binário. Workloads precisavam da permissão nodes/proxy para acessar qualquer endpoint HTTPS do Kubelet — seja para fins inofensivos, como ler uma métrica de um DaemonSet do Prometheus, ou para ações de alto privilégio, como executar comandos dentro de um container com kubectl exec.

Para times de engenharia e operações no Brasil, isso sempre representou um "pesadelo" de segurança: conceder nodes/proxy para um agente de monitoramento significa, na prática, dar a ele o poder de superusuário no nó. Se o agente for comprometido, o atacante ganha controle total sobre todos os pods hospedados naquele host.

A vulnerabilidade crítica via WebSocket

A urgência dessa transição GA é sustentada por descobertas recentes que evidenciam como o uso do verbo get dentro do modelo nodes/proxy pode ser explorado para execução remota de código (RCE). O handshake do protocolo WebSocket (RFC 6455) é interpretado pelo Kubelet como uma requisição HTTP GET, o que permite o bypass da autorização de escrita, possibilitando o exec arbitráro via porta 10250:

Copiarwebsocat --insecure \
  --header "Authorization: Bearer $TOKEN" \
  --protocol v4.channel.k8s.io \
  "wss://$NODE_IP:10250/exec/default/nginx/nginx?output=1&error=1&command=id"

Essa vulnerabilidade expõe, inclusive, diversos Helm charts populares que ainda utilizam a configuração permissiva nodes/proxy como padrão.

Como a autorização granular altera o cenário

Com o recurso em GA, o Kubelet introduz sub-recursos específicos (nodes/metrics, nodes/stats, nodes/pods, etc.). Agora, ao configurar um ClusterRole de monitoramento, você aplica o princípio do least privilege:

CopiarapiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: monitoring-agent
rules:
- apiGroups: [""]
  resources: ["nodes/metrics", "nodes/stats"]
  verbs: ["get"]

Impactos para operações corporativas

1. Compatibilidade: A atualização é transparente. O Kubelet executa um dual-check: ele tenta a autorização granular primeiro e, caso falhe, faz o fallback para o nodes/proxy. Isso garante que workloads legadas continuem funcionando durante a transição.
2. Hardening automatizado: O system:kubelet-api-admin já vem atualizado para contemplar todos os novos sub-recursos, assegurando que o kube-apiserver mantenha o controle total sem intervenção manual.
3. Auditoria: Recomendamos que times de SecOps iniciem o mapeamento de todos os ClusterRoleBindings que utilizam nodes/proxy. O objetivo deve ser a substituição total por recursos granulares nos próximos ciclos de deployment.

Recomendamos fortemente que empresas que possuem grandes clusters em produção iniciem a migração das permissões de seus agentes de monitoramento e scraping de métricas imediatamente. O status GA desta funcionalidade é um convite maduro para elevar a postura de segurança do seu ecossistema Kubernetes.

---

Artigo originalmente publicado em Kubernetes Blog.