Kubernetes 1.37 leva o modo rootless para beta e muda o jogo da segurança no nó

O Kubernetes↳Kubernetes18 conteúdosGerenciamento de infraestrutura multicloud com Kubernetes proporciona otimização e economiaDevSecOps · set 2021Azure Kubernetes Services – AKS: referências gratuitas e dicas para solução de problemas comunsDevSecOps · abr 2019Kubernetes em produção: o que ninguém te conta e você aprende tarde demaisDev (Back & Front) · abr 2026Ver tudo em DevSecOps → 1.37 promoveu o feature gate KubeletInUserNamespace, o chamado rootless mode, de alpha para beta. A mudança está descrita no blog oficial do projeto, em texto assinado por Akihiro Suda (NTT), justamente o autor do experimento que originou o recurso em 2018 e virou alpha na v1.22, em 2021.

O que ele faz é simples de enunciar e pesado nas consequências: com o rootless habilitado, todos os componentes de nó (kubelet, runtimes CRI e OCI, plugins de CNI e o kube-proxy) rodam como um usuário não-root no host, dentro de um Linux user namespace. O UID 0 de dentro do namespace é um root falso, mapeado para um UID comum lá fora (por exemplo, 1000).

Por que isso importa para quem opera cluster

A razão é histórica e concreta: os componentes de nó já foram porta de entrada para uma sequência de falhas de container breakout que, quando exploradas, davam root de verdade na máquina. O post lista os casos pelo nome, e a lista é desconfortável de ler para quem mantém frota em produção:

| CVE | Componente | O que permitia | |---|---|---| | CVE-2022-0811 (cr8escape) | CRI-O | Definir sysctls arbitrários (kernel.core_pattern) e executar código como root no host | | CVE-2023-27561 | runc | Burlar masked paths via race em volume mount, expondo o procfs do host | | CVE-2024-10220 | kubelet | Executar comandos arbitrários como root via volumes gitRepo | | CVE-2025-31133 | runc | Bind-mount de caminhos controlados pelo atacante em /proc/sysrq-trigger e afins | | CVE-2026-53488 | containerd | Executar comandos no host via labels forjadas em imagem |

A promessa do rootless não é impedir que essas falhas existam, e sim conter o raio de explosão. Se o kubelet e o runtime rodam sob uma conta comum, um breakout bem-sucedido chega, no máximo, aos privilégios daquela conta. O atacante não consegue, segundo o texto, ocultar a invasão mexendo no kernel, no bootloader ou no firmware. É uma diferença de categoria: em vez de comprometimento total do host, o incidente vira comprometimento de um usuário.

O trade-off precisa ficar explícito, e o próprio projeto o coloca: user namespace não protege contra vulnerabilidades no kernel em si. Ele é uma camada, não um substituto para o resto do hardening. A recomendação continua sendo combiná-lo com seccomp para reduzir a superfície de syscalls.

Rootless de nó não é user namespace de pod

Aqui mora a confusão mais provável, e o post faz questão de separar. KubeletInUserNamespace (rootless mode) coloca os componentes de nó em user namespace. Já hostUsers: false, sob o gate UserNamespacesSupport (GA desde a v1.36), coloca os pods em user namespace, mas mantém os componentes de nó rodando como root.

São coisas distintas e não conflitantes. Melhor: podem ser combinadas para aninhar Kubernetes dentro de Kubernetes sem recorrer ao privileged: true, isolando workloads de forma mais estrita do que namespaces de API conseguem.

Como funciona por baixo

O root falso do namespace dá conta da maior parte do trabalho dos componentes de nó: montar volumes, criar cgroups e configurar os network namespaces dos pods. O feature gate em si é descrito pelo autor como "boring": ele basicamente faz o kubelet ignorar erros de permissão que aparecem ao tentar setar certos sysctls (como vm.overcommit_memory e kernel.panic) e ao ler mensagens do kernel via /dev/kmsg.

O detalhe operacional relevante é que o user namespace tem que ser criado fora do Kubernetes. O caminho comum é usar Rootless Docker para preparar o namespace em que o cluster vai rodar. E há avisos de compatibilidade: alguns drivers de CNI e CSI podem quebrar sob rootless, então isso não é um interruptor que se liga sem validar a stack.

Parte da viabilidade atual veio de melhorias fora do próprio gate, que valem citar porque explicam por que o beta chega agora e não antes:

• Kernel Linux 6.3 (2023): suporte a idmapped tmpfs.
• Kubernetes 1.33 (2025): UserNamespacesSupport ligado por padrão, liberando pods com hostUsers: false sem configuração extra.
• containerd 2.1 (2025): suporte a cgroups graváveis.

O que muda do alpha para o beta

O ponto prático: o feature gate agora vem habilitado por padrão. Isso não significa que seu cluster "rootful" existente muda de comportamento. Habilitar o gate não coloca o kubelet em user namespace automaticamente. Para clusters tradicionais, nada muda.

O que aparece de novo e é útil para operação é a introspecção. O comando kubectl get nodes -o yaml agora reporta se um nó roda em user namespace, via a propriedade runningInUserNamespace. Com isso, dá para o administrador aplicar labels ou taints e evitar agendar em nó rootless workloads que precisam de root de verdade, como certos instaladores de CNI. Isso é exatamente o tipo de sinal que operador precisa para tomar decisão de scheduling sem adivinhação.

O projeto também passou a rodar os testes de conformidade de nó (e2e) num cluster rootless (ci-kubernetes-e2e-kind-rootless), o que dá alguma garantia de que o caminho é exercitado no CI e não só na teoria.

Onde ele encaixa (e onde não)

O post enumera casos de uso que ajudam a calibrar expectativa:

• Clusters de produção: mitigar breakout.
• Máquinas compartilhadas (HPC): subir Kubernetes sem pedir root ao admin da máquina, sem risco de quebrar o ambiente de outros usuários.
• Laptops: evitar que um cluster local mexa nas regras de iptables do host (as de VPN, por exemplo).
• Sandbox de IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI →: rodar um agente de codar e um cluster de teste sob uma conta dedicada, para que o agente, se enganado por informação maliciosa da internet, não quebre o host. Para quem está experimentando agentes de IA localmente, esse é um isolamento barato e sensato.
• Kubernetes-in-Kubernetes e bootstrapping (cluster temporário sem privilégio para subir o cluster real, via Cluster API).

O lado do "não vale a pena": se sua stack depende de drivers de CNI/CSI incompatíveis, ou se o workload precisa de root real no host, rootless vai atrapalhar mais do que ajudar. E, de novo, ele não substitui hardening de kernel.

Como testar hoje

O caminho mais curto para colocar a mão é o kind, rodando sobre Docker rootless:

dockerd-rootless-setuptool.sh install
kind create cluster

Dependendo do host, pode ser preciso ajuste em systemd, módulos de kernel e sysctl. O minikube também suporta o modo, com minikube start --driver=docker sobre Docker rootless. Para cenários mais próximos de produção, o Usernetes (mantido pelo próprio autor) cria clusters rootless multi-nó conectados por VXLAN via Flannel, e o k3s oferece rootless sem depender de um runtime externo como o Rootless Docker.

O plano é graduar para GA em versão futura, dependendo de feedback e adoção, com KEPs em discussão (KEP-5474 sobre cgroups graváveis e KEP-5714 sobre unshare de cgroup namespaces) para simplificar o aninhamento. Para quem opera cluster no Brasil, o recado é começar a validar rootless em ambiente de teste agora: o interruptor de segurança está pronto, mas ligá-lo com CNI e CSI da sua stack ainda pede medição antes de ir para produção.

Fonte: Kubernetes Blog