Kubernetes 1.37 brings rootless mode to beta and changes the node security game

Kubernetes 1.37 promoted the KubeletInUserNamespace feature gate, the so-called rootless mode, from alpha to beta. The change is described in the project's official blog, in a post signed by Akihiro Suda (NTT), precisely the author of the experiment that originated the feature in 2018 and became alpha in v1.22, in 2021.

What it does is simple to state and heavy in consequences: with rootless enabled, all node components (kubelet, CRI and OCI runtimes, CNI plugins, and kube-proxy) run as a non-root user on the host, inside a Linux user namespace. UID 0 inside the namespace is a fake root, mapped to a regular UID outside (for example, 1000).

Why this matters for cluster operators

The reason is historical and concrete: node components have already been an entry point for a series of container breakout flaws that, when exploited, granted real root on the machine. The post lists the cases by name, and the list is uncomfortable to read for anyone running a fleet in production:

| CVE | Component | What it allowed | |---|---|---| | CVE-2022-0811 (cr8escape) | CRI-O | Setting arbitrary sysctls (kernel.core_pattern) and executing code as root on the host | | CVE-2023-27561 | runc | Bypassing masked paths via a race in volume mount, exposing the host's procfs | | CVE-2024-10220 | kubelet | Executing arbitrary commands as root via gitRepo volumes | | CVE-2025-31133 | runc | Bind-mounting attacker-controlled paths onto /proc/sysrq-trigger and similar | | CVE-2026-53488 | containerd | Executing commands on the host via forged image labels |

The promise of rootless is not to prevent these flaws from existing, but to contain the blast radius. If kubelet and the runtime run under a regular account, a successful breakout reaches, at most, the privileges of that account. According to the text, the attacker cannot hide the intrusion by tampering with the kernel, the bootloader, or the firmware. It's a difference in kind: instead of full host compromise, the incident becomes a user compromise.

The trade-off needs to be explicit, and the project itself states it: user namespace does not protect against vulnerabilities in the kernel itself. It is a layer, not a substitute for the rest of the hardening. The recommendation remains to combine it with seccomp to reduce the syscall surface.

Node rootless is not pod user namespace

This is where the most likely confusion lies, and the post makes a point of separating the two. KubeletInUserNamespace (rootless mode) puts node components in a user namespace. hostUsers: false, on the other hand, under the UserNamespacesSupport gate (GA since v1.36), puts pods in a user namespace, but keeps node components running as root.

These are distinct, non-conflicting things. Better yet: they can be combined to nest Kubernetes inside Kubernetes without resorting to privileged: true, isolating workloads more strictly than API namespaces can.

How it works under the hood

The namespace's fake root handles most of the node components' work: mounting volumes, creating cgroups, and configuring pods' network namespaces. The feature gate itself is described by the author as "boring": it basically makes kubelet ignore permission errors that come up when trying to set certain sysctls (such as vm.overcommit_memory and kernel.panic) and when reading kernel messages via /dev/kmsg.

The relevant operational detail is that the user namespace has to be created outside of Kubernetes. The common path is to use Rootless Docker to prepare the namespace the cluster will run in. And there are compatibility warnings: some CNI and CSI drivers can break under rootless, so this isn't a switch you flip without validating your stack.

Part of the current feasibility came from improvements outside the gate itself, worth citing because they explain why beta arrives now and not earlier:

• Linux kernel 6.3 (2023): support for idmapped tmpfs.
• Kubernetes 1.33 (2025): UserNamespacesSupport enabled by default, unlocking pods with hostUsers: false without extra configuration.
• containerd 2.1 (2025): support for writable cgroups.

What changes from alpha to beta

The practical point: the feature gate now comes enabled by default. This does not mean your existing "rootful" cluster changes behavior. Enabling the gate does not automatically put kubelet into a user namespace. For traditional clusters, nothing changes.

What's new and useful for operations is introspection. The kubectl get nodes -o yaml command now reports whether a node runs in a user namespace, via the runningInUserNamespace property. With that, administrators can apply labels or taints to avoid scheduling workloads that need real root, such as certain CNI installers, onto rootless nodes. This is exactly the kind of signal an operator needs to make scheduling decisions without guesswork.

The project also started running node conformance tests (e2e) on a rootless cluster (ci-kubernetes-e2e-kind-rootless), which gives some assurance that the path is exercised in CI and not just in theory.

Where it fits (and where it doesn't)

The post lists use cases that help calibrate expectations:

• Production clusters: mitigating breakout.
• Shared machines (HPC): spinning up Kubernetes without asking the machine admin for root, without risking breaking other users' environment.
• Laptops: preventing a local cluster from touching the host's iptables rules (VPN rules, for example).
• AI sandboxing: running a coding agent and a test cluster under a dedicated account, so that the agent, if fooled by malicious information from the internet, doesn't break the host. For anyone experimenting with AI agents locally, this is cheap and sensible isolation.
• Kubernetes-in-Kubernetes and bootstrapping (a temporary, unprivileged cluster to bring up the real cluster, via Cluster API).

The "not worth it" side: if your stack depends on incompatible CNI/CSI drivers, or if the workload needs real root on the host, rootless will get in the way more than it helps. And, again, it doesn't replace kernel hardening.

How to test it today

The shortest path to get hands-on is kind, running on top of rootless Docker:

dockerd-rootless-setuptool.sh install
kind create cluster

Depending on the host, adjustments to systemd, kernel modules, and sysctl may be needed. minikube also supports the mode, with minikube start --driver=docker on top of rootless Docker. For scenarios closer to production, Usernetes (maintained by the author himself) creates multi-node rootless clusters connected by VXLAN via Flannel, and k3s offers rootless without depending on an external runtime like Rootless Docker.

The plan is to graduate to GA in a future release, depending on feedback and adoption, with KEPs under discussion (KEP-5474 on writable cgroups and KEP-5714 on unsharing cgroup namespaces) to simplify nesting. For cluster operators in Brazil, the takeaway is to start validating rootless in a test environment now: the security switch is ready, but flipping it with your stack's CNI and CSI still requires measurement before going to production.