Kubernetes 1.37 promove o modo rootless a beta

O Kubernetes v1.37 promove a beta o feature gate KubeletInUserNamespace. Com ele ativo, cada componente do nó pode correr como um utilizador comum em vez de root. Akihiro Suda, da NTT, anunciou a mudança no blogue do Kubernetes a 4 de setembro de 2026. A versão v1.37.0 saiu a 26 de agosto de 2026.

O objetivo é limitar estragos. Se alguém escapar de um contentor, cai numa conta sem privilégios e não como root na máquina.

O que corre mesmo sem root

Suda enumera quatro tipos de componente de nó abrangidos pela funcionalidade:

• o kubelet
• os runtimes de contentores CRI e OCI
• os plugins de rede CNI
• o kube-proxy

Todos eles "can run as a non-root user on the host, using a Linux user namespace", escreve. "This technique is also known as rootless mode."

Um espaço de nomes de utilizador é uma funcionalidade do núcleo do Linux. Um processo julga-se root dentro do seu próprio mundo, enquanto o anfitrião continua a tratá-lo como utilizador comum. Os privilégios são reais lá dentro e inexistentes cá fora.

É este todo o argumento de segurança. Suda expõe o motivo sem rodeios: os componentes do nó têm "historically had container-breakout vulnerabilities that could compromise full root privileges on the host." O texto cita cinco.

• CVE-2022-0811
• CVE-2023-27561
• CVE-2024-10220
• CVE-2025-31133
• CVE-2026-53488

Em modo rootless, uma fuga por qualquer uma delas chega a uma conta de utilizador normal. Não chega ao root do anfitrião.

A distinção que muita gente vai confundir

Existem duas funcionalidades diferentes de espaços de nomes de utilizador no Kubernetes, e confundem-se com facilidade.

Suda traça a linha ele próprio. O modo rootless "should not be confused with user namespaces for pods", escreve. Essa outra funcionalidade ativa-se com hostUsers: false e o feature gate UserNamespacesSupport. Está geralmente disponível desde a v1.36. Essa funcionalidade "puts pods in user namespaces but still runs the node components as root."

Ou seja, uma põe as suas cargas de trabalho num espaço de nomes. A outra põe lá a maquinaria. Resolvem metades diferentes do mesmo problema e, segundo o texto, podem ser combinadas.

Sete anos da experiência à beta

Esta funcionalidade avançou devagar, e as datas dizem algo sobre a sua dificuldade.

Fase	Quando
Primeira experiência	2018
Alfa, como KEP-2033	v1.22, em 2021
Beta	v1.37, em 2026

Entre a alfa e a beta passaram cinco anos. Correr o kubelet sem root mexe ao mesmo tempo com runtimes de contentores, plugins de rede e gestão de cgroups, e cada um teve de criar o seu próprio suporte.

Um KEP é uma Kubernetes Enhancement Proposal, o documento de desenho escrito por onde uma mudança destas tem de passar. É o mesmo formato de processo que a GNOME está agora a redigir para si.

O que isto significa para programadores

Verifique primeiro quem corre o seu kubelet. Se usa um serviço gerido como EKS, GKE ou AKS, esse processo não é seu e esta funcionalidade não está ao seu alcance. Conta sobretudo para quem gere os próprios nós, monta um cluster de testes ou instala na periferia.

Leia o anúncio e os requisitos antes de experimentar. O modo rootless assenta em comportamentos concretos do núcleo, versões concretas de runtime e delegação de cgroups, e o texto de Suda é onde esses detalhes estão. Não assuma que a sua imagem de nó atual serve.

Trate a beta como beta. No Kubernetes isso quer dizer que a forma da API está razoavelmente assente mas as arestas operacionais não, e que os feature gates ainda podem mudar de valor por omissão entre versões. Corra isto onde possa dar-se ao luxo de perder.

A conclusão útil aplica-se mesmo que nunca a ative. Pergunte o que uma fuga de contentor alcança hoje nos seus nós. Na maioria dos clusters a resposta honesta é o root do anfitrião, e essa resposta passa a ser uma escolha em vez de um dado adquirido.