Kubernetes 1.37 promotes rootless mode to beta

Kubernetes v1.37 promotes the KubeletInUserNamespace feature gate to beta. With it enabled, every node component can run as an ordinary user instead of root. Akihiro Suda of NTT announced the change on the Kubernetes blog on September 4, 2026. The v1.37.0 release itself landed on August 26, 2026.

The point is damage control. If someone escapes a container, they land in an unprivileged account rather than as root on the machine.

What actually runs as non-root

Suda lists four kinds of node component that the feature covers:

• the kubelet
• CRI and OCI container runtimes
• CNI networking plugins
• kube-proxy

All of them "can run as a non-root user on the host, using a Linux user namespace," he writes. "This technique is also known as rootless mode."

A user namespace is a Linux kernel feature. It lets a process believe it is root inside its own little world, while the host still treats it as an ordinary user. The privileges are real inside the namespace and absent outside it.

That is the whole security argument. Suda puts the motivation plainly: the node components have "historically had container-breakout vulnerabilities that could compromise full root privileges on the host." His post cites five of them.

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

Under rootless mode, a break out of any of those reaches a normal user account. It does not reach host root.

The distinction people will get wrong

There are two different user-namespace features in Kubernetes, and they are easy to confuse.

Suda draws the line himself. Rootless mode "should not be confused with user namespaces for pods," he writes. That other feature is switched on with hostUsers: false and the UserNamespacesSupport feature gate. It has been generally available since v1.36. It "puts pods in user namespaces but still runs the node components as root."

So one puts your workloads in a namespace. The other puts the machinery in one. They solve different halves of the same problem, and the post says they can be combined.

Seven years from experiment to beta

This feature has moved slowly, and the dates say something about its difficulty.

Stage	When
First experiment	2018
Alpha, as KEP-2033	v1.22, in 2021
Beta	v1.37, in 2026

Five years passed between alpha and beta. Running the kubelet without root touches container runtimes, networking plugins and cgroup management all at once, and each of those had to grow its own support.

A KEP is a Kubernetes Enhancement Proposal, the written design document a change like this has to pass through. It is the same shape of process that GNOME is now drafting for itself.

What this means for developers

Check who runs your kubelet before you plan anything. If you use a managed service such as EKS, GKE or AKS, you do not control that process, and this feature is not yours to switch on. It matters most to people running their own nodes, and to anyone building a test cluster or an edge deployment.

Read the announcement for the requirements before you try it. Rootless mode leans on specific kernel behavior, container runtime versions and cgroup delegation, and Suda's post is where those specifics live. Do not assume your current node image qualifies.

Treat beta as beta. In Kubernetes that means the API shape is fairly settled but the operational edges are not, and feature gates can still change defaults between releases. Run it somewhere you can afford to lose.

The useful takeaway holds even if you never enable it. Ask what a container escape actually reaches on your nodes today. For most clusters the honest answer is host root, and that answer is now a choice rather than a given.