Kubernetes 1.37 Promotes Rootless Mode for Node Components to Beta
Kubernetes v1.37 enables KubeletInUserNamespace by default: the kubelet, runtimes, and CNI plugins can now run as a non-root user inside a user namespace. Turn it on to confine container-breakout flaws away from host root.
September 4, 2026. Kubernetes v1.37 promotes KubeletInUserNamespace — known as rootless mode — to beta, and it is now enabled by default. The work began as an experiment in 2018 and was merged as alpha in v1.22 (2021) via KEP-2033. Why it matters: node components have historically racked up container-breakout flaws that yielded full host root. Rootless mode shrinks the blast radius of those flaws to a single non-root account.
The node finally runs without root
With the feature enabled, every node component — the kubelet, the CRI and OCI runtimes, CNI plugins, and kube-proxy — runs as a non-root user on the host, inside a Linux user namespace. That is the precise definition of rootless mode, popularized by Docker and Podman.
Do not confuse it with user namespaces for pods (hostUsers: false, via the UserNamespacesSupport gate, GA since v1.36), which place pods in user namespaces but still run node components as root. The two do not conflict, and can even be combined to nest Kubernetes inside Kubernetes without resorting to privileged: true.
How it works under the hood
A Linux user namespace maps a non-root host UID — say 1000 — to a fake root (UID 0) inside the namespace. Those UID 0 privileges are then confined to the inside of the namespace: the fake root is enough for most node work — mounting volumes, creating cgroups, configuring the network namespaces of pods — but it has no authority over the host.
The namespace must be created outside Kubernetes, for instance with rootless Docker, rootless Podman, or nerdctl. The KubeletInUserNamespace gate itself stays deliberately “boring”: it mostly makes the kubelet ignore permission errors when setting a few sysctls — such as vm.overcommit_memory or kernel.panic — and when watching kernel messages via /dev/kmsg.
That restraint is a sign of good design. The feature does not rewrite the kubelet: it makes it compatible with an already-provisioned non-root environment, which limits the regression surface. The one caveat is compatibility: a handful of CNI and CSI drivers still assume real root, so rootless may not be a drop-in for every node.
Why now: a history of escapes
The motivation reads as a list of CVEs, each of which led to root code execution on the host:
- CVE-2022-0811 (“cr8escape”): CRI-O could be tricked into setting arbitrary sysctls such as
kernel.core_pattern, leading to root code execution. - CVE-2023-27561: runc could bypass masked paths via a volume-mount race, exposing the host’s procfs (a regression of CVE-2019-19921).
- CVE-2024-10220: the kubelet could run arbitrary commands as root via gitRepo volumes (a similar flaw, CVE-2018-11235, dated back to 2018).
- CVE-2025-31133: runc could bind-mount attacker-controlled paths and write to procfs files such as
/proc/sysrq-trigger. - CVE-2026-53488: containerd could execute commands on the host via labels crafted in a container image.
Running node components inside a user namespace confines the damage to the non-root account. Notably, an attacker can no longer hide an intrusion by modifying the kernel, boot loader, or firmware.
One limit to keep in mind: user namespaces do not mitigate flaws in the kernel itself. Pair them with traditional hardening such as seccomp to block unnecessary system calls.
Rootless therefore belongs in a defense-in-depth strategy, not a promise of total isolation. For genuinely hostile workloads — untrusted code run in production — stack it with runtime sandboxes like gVisor or Kata Containers, which interpose a stronger boundary between the workload and the kernel. Rootless lowers the cost of a node-level flaw; it does not replace workload segmentation or network policy.
What changed from alpha to beta
The beta transition is deliberately quiet, and that is a good thing. The gate is now enabled by default, but enabling it does not drop the kubelet into a user namespace automatically — so nothing changes for existing “rootful” clusters.
kubectl get nodes -o yaml now reports whether a node runs in a user namespace via the runningInUserNamespace property. An administrator can use it to set labels or taints, keeping workloads that need real root (for example, some CNI plugin installers) off rootless nodes.
Operationally, the migration is gentle. Because enabling the gate does not drop existing nodes into a user namespace, a cluster can be converted incrementally: new or rebuilt nodes come up rootless while the rest stay rootful. The runningInUserNamespace property then lets you taint rootless nodes so that only workloads compatible with non-root operation — no privileged installers, no direct device access — land on them. That incremental path is what makes the beta practical for production, rather than forcing a big-bang re-provisioning.
On the quality side, the end-to-end conformance tests now run on a rootless cluster (ci-kubernetes-e2e-kind-rootless), anchoring the feature in the project’s own validation cycle.
Concrete use cases
Rootless covers a wider spectrum than production alone. On shared machines — an HPC cluster, for instance — users can deploy Kubernetes without asking the machine administrator for root, and without risking breaking other users’ environments. On a laptop, a rootless local cluster can no longer damage the host configuration, such as the iptables rules a VPN relies on.
Two emerging uses stand out. First, the AI sandbox: a developer can create a dedicated local account to run a coding agent and a test cluster, stopping an agent deceived by malicious content from compromising the host. Second, bootstrapping: a temporary unprivileged cluster can bring up a real cluster, for example via Cluster API.
How to use it
The easiest path is kind, which can start a cluster in rootless Docker, rootless nerdctl, or rootless Podman:
dockerd-rootless-setuptool.sh install
kind create clusterminikube also supports rootless mode via rootless Docker or Podman, as does k3s, which depends on no external runtime. For multi-node setups, Usernetes — maintained by the feature’s author, Akihiro Suda — links several rootless nodes over VXLAN with the Flannel plugin.
Rootless did not arrive alone. Several improvements made it viable upstream: kernel Linux 6.3 (2023) added idmapped tmpfs support, Kubernetes v1.33 (2025) enabled UserNamespacesSupport by default, and containerd v2.1 (2025) added writable cgroups. Thanks to those, a cluster with KubeletInUserNamespace can now be nested inside hostUsers: false pods.
On the roadmap, the feature is headed toward general availability (GA) in a future release, depending on feedback. The project is also discussing KEPs that will simplify Kubernetes-in-Kubernetes: KEP-5474 (writable cgroups for unprivileged containers) and KEP-5714 (optionally not unsharing cgroup namespaces).
Verdict
If you operate a production cluster, enable KubeletInUserNamespace on nodes whose CNI and CSI tolerate it: it is the cheapest attack-surface reduction available against the container-breakout class, with a migration cost near zero because the gate leaves existing clusters untouched.
If you run shared machines (HPC) or on-laptop dev clusters, replace your “rootful” clusters with kind, minikube, or k3s in rootless mode: you eliminate an entire class of host-root compromise, including when a local AI agent gets deceived by malicious content.
If your workload genuinely needs real root (some CNI installers, direct device access), keep it on dedicated, tainted nodes and confine everything else to rootless.