Kubernetes v1.37 promotes the KubeletInUserNamespace
feature gate to beta.
With this feature enabled, all of the node components (kubelet, CRI and OCI runtimes,
CNI plugins, and kube-proxy) can run as a non-root user on the host, using a
Linux user namespace.
This technique is also known as rootless mode.
The work started as an experiment in 2018, and was merged into Kubernetes v1.22 (2021)
as an alpha feature (Kubernetes Enhancement Proposal KEP-2033).
This feature should not be confused with user namespaces for pods
(hostUsers: false
with the UserNamespacesSupport
feature gate, GA since v1.36),
which puts pods in user namespaces but still runs the node components as root.
These two features do not conflict.
Moreover, they can be combined to nest Kubernetes inside Kubernetes without resorting to
the full privileged: true
.
Why run the node components in a user namespace?
Because the node components have historically had container-breakout vulnerabilities that could compromise full root privileges on the host.
Examples of such vulnerabilities include:
- CVE-2022-0811
("cr8escape"): CRI-O could be tricked into setting arbitrary sysctls, such as
kernel.core_pattern
, resulting in arbitrary code execution as root on the host - CVE-2023-27561: runc could be tricked into bypassing the masked paths of a container via a volume mount race, exposing the host's procfs files (a regression of CVE-2019-19921)
- CVE-2024-10220:
the kubelet could be made to execute arbitrary commands as root via
gitRepo
volumes (gitRepo
volumes had a similar vulnerability, CVE-2018-11235, back in 2018 too) - CVE-2025-31133:
runc could be tricked into bind-mounting attacker-controlled paths and writing to the
host's procfs files, such as
/proc/sysrq-trigger
and/proc/sys/kernel/core_pattern
- CVE-2026-53488: containerd could be tricked into executing arbitrary commands on the host, via crafted labels in a container image
By running the node components in a user namespace, the potential damage is confined to the non-root user's account. Notably, an attacker cannot conceal their intrusion by modifying the kernel, the boot loader, or the firmware.
It should still be noted that user namespaces are not effective for mitigating vulnerabilities in the kernel itself. User namespaces should be used in conjunction with traditional hardening measures such as seccomp to prevent containers from invoking unnecessary system calls.
Use cases
- Production clusters: mitigate potential container-breakout vulnerabilities.
- Shared machines (e.g., HPC): users can deploy Kubernetes without asking the machine administrator for root privileges, and without the risk of accidentally breaking other users' environments.
- Laptops: prevent a local cluster from accidentally breaking the host system configuration, e.g., the host iptables rules used for VPNs.
- AI sandbox: a Kubernetes application developer may create a dedicated local user account for running an AI coding agent and a test Kubernetes cluster. This setup is useful for preventing the AI agent from breaking the host when it is deceived by malicious information on the Internet.
- Kubernetes-in-Kubernetes: a nested cluster can run inside a parent cluster as a user-namespaced
pod (
hostUsers: false
), isolating workloads more strictly than Kubernetes API namespaces do. - Bootstrapping: a temporary unprivileged cluster can be used to bootstrap an actual cluster, e.g., with Cluster API.
How does it work?
A Linux kernel user namespace maps a host level non-root user (e.g., UID 1000) to a fake root user inside the namespace. The UID 0 privileges are limited to the inside of the namespace. The fake root is enough for most of the node components' tasks: mounting volumes, creating cgroups, and configuring the network namespaces of pods. It still comes with some caveats that may break compatibility with specific CNI and CSI drivers, though.
The user namespace has to be created outside of Kubernetes. For example, Rootless Docker can be used to prepare the user namespace in which Kubernetes runs.
The KubeletInUserNamespace
feature gate itself is quite "boring": basically it just lets the kubelet
ignore permission errors that occur when setting some sysctl values
(e.g., vm.overcommit_memory
and kernel.panic
)
and when watching kernel messages via /dev/kmsg
.
See Running Kubernetes Node Components as a Non-root User for further information.
What changed from Alpha to Beta?
- The
KubeletInUserNamespace
feature gate is now enabled by default. Enabling the gate does not put the kubelet into a user namespace automatically, so nothing changes for existing "rootful" clusters. kubectl get nodes -o yaml
now reports whether nodes are running in a user namespace via therunningInUserNamespace
property. A cluster administrator can use this property to set node labels or taints, to avoid scheduling workloads that need real root privileges (e.g., some CNI plugin installers) onto rootless nodes.- For Kubernetes' own CI/CD testing, the node conformance end to end tests now run on a rootless cluster (ci-kubernetes-e2e-kind-rootless).
Several related improvements have also happened outside the promotion of the feature gate itself:
- Linux kernel v6.3 (2023): added support for idmapped tmpfs.
- Kubernetes v1.33 (2025): enabled the
UserNamespacesSupport
feature gate by default, allowing user-namespaced pods (hostUsers: false
) to be created without extra configuration. - containerd v2.1 (2025): added support for writable cgroups.
With these improvements, a Kubernetes cluster with KubeletInUserNamespace
can now also be nested
inside Kubernetes pods with hostUsers: false
(UserNamespacesSupport
).
How to use it
kind
The easiest way is to use kind (a Kubernetes SIG Testing project) to run a Kubernetes cluster in rootless Docker, rootless nerdctl, or rootless Podman:
Example using Docker
dockerd-rootless-setuptool.sh install
kind create cluster
Depending on the host configuration, you may need additional configuration for systemd, kernel modules, sysctl, etc.
See the Docker documentation and the kind documentation for further information.
minikube
minikube (a Kubernetes SIG Cluster Lifecycle project) also supports running a Kubernetes cluster in rootless Docker or rootless Podman:
dockerd-rootless-setuptool.sh install
minikube start --driver=docker
See the minikube documentation for further information.
Usernetes
Usernetes (a third-party project)
is a distribution of rootless Kubernetes, maintained by the author of this article.
The project began in 2018, and it is where the KubeletInUserNamespace
feature gate
originally came from.
Unlike kind and minikube, Usernetes supports creating a cluster with multiple rootless Docker / Podman / nerdctl nodes, connected using VXLAN via the Flannel CNI plugin.
Usernetes also experimentally supports a Kubernetes-in-Kubernetes mode.
k3s
k3s (a CNCF Sandbox project) also supports rootless mode. Unlike kind, minikube, and the current generation of Usernetes, rootless k3s does not rely on an external runtime such as rootless Docker.
What's next?
Depending on feedback and adoption, the Kubernetes project plans to graduate this feature to General Availability (GA) in a future release. If you have feedback on this feature, please open an issue in the kubernetes/kubernetes repository.
The project is also discussing several Kubernetes Enhancement Proposals that may contribute to simplifying Kubernetes-in-Kubernetes with this feature:
- KEP-5474: Enable Writable cgroups for unprivileged containers
- KEP-5714: Allow specifying whether to unshare cgroup namespaces
Getting involved
We always welcome new contributors. If you would like to get involved, you can join the Node Special Interest Group (SIG Node).
If you would like to share feedback, you can do so on our public Slack channel (visit https://slack.k8s.io/ for an invitation if you need one).
Special thanks to everyone who helped design and implement this feature, including but not limited to (in alphabetical order):
- Bing Hongtao (HirazawaUi)
- Jordan Liggitt (liggitt)
- Sergey Kanzhelev (SergeyKanzhelev)
- Tim Hockin (thockin)
Facts Only
* Kubernetes v1.37 promotes the KubeletInUserNamespace feature gate to beta.
* The feature allows kubelet, CRI, OCI runtimes, CNI plugins, and kube-proxy to run as non-root users via Linux user namespaces.
* KEP-2033 was merged into Kubernetes v1.22 as an alpha feature.
* User namespaces for pods (hostUsers: false) became GA in v1.36.
* Cited vulnerabilities include CVE-2022-0811, CVE-2023-27561, CVE-2024-10220, CVE-2025-31133, and CVE-2026-53488.
* Linux kernel v6.3 added support for idmapped tmpfs.
* Kubernetes v1.33 enabled UserNamespacesSupport by default.
* containerd v2.1 added support for writable cgroups.
* Implementation options include kind, minikube, Usernetes, and k3s.
* The KubeletInUserNamespace gate is now enabled by default in v1.37.
Executive Summary
Kubernetes v1.37 introduces the beta promotion of "rootless mode" via the KubeletInUserNamespace feature. This capability allows core node components—including the kubelet and various runtimes—to operate as non-root users on a host. By mapping a host-level non-root user to a fake root user within a Linux user namespace, the system limits the potential impact of container-breakout vulnerabilities. If a component is compromised, the attacker's privileges are confined to the non-root account rather than gaining full host root access.
This development is distinct from, though compatible with, user namespaces for pods. Together, they enable "Kubernetes-in-Kubernetes" nesting without requiring full privileged access. While this enhances security for production clusters and provides flexibility for shared HPC environments, laptops, and AI sandboxes, some compatibility issues with specific CNI and CSI drivers may persist. Implementation currently relies on external runtimes like rootless Docker or Podman for most tools, though k3s offers a standalone rootless approach.
Full Take
The strongest version of this narrative is a technical evolution toward "least privilege" architecture. By decoupling the management of a cluster from the absolute authority of the host's root user, the system structurally reduces the blast radius of inevitable software vulnerabilities. This is a pragmatic admission that "breakouts" happen, shifting the goal from perfect prevention to contained failure.
This is a technical announcement from a project contributor. It follows a standard engineering progression—alpha to beta to GA—and relies on CVE citations to justify the necessity of the feature. There is no load-bearing attempt to manipulate the reader; the risks (compatibility caveats) and limitations (kernel vulnerabilities) are explicitly stated.
Patterns detected: none
The driving paradigm is the shift toward "zero trust" at the infrastructure level. Historically, the orchestrator was the "god-process" of the node. Moving toward rootless mode echoes the broader industry trend of removing implicit trust from system daemons. This empowers the end-user—specifically those in shared or restricted environments—by removing the "administrator bottleneck," effectively democratizing cluster deployment.
However, a second-order consequence is the increased complexity of the networking and storage stack. As we add layers of namespace mapping, the "magic" of how a packet gets from a pod to the wire becomes more opaque, potentially creating new categories of debugging challenges.
Bridge Questions:
1. How does the shift to rootless mode affect the performance overhead of system calls and I/O operations?
2. Which specific CNI/CSI drivers are most likely to break, and are those vendors incentivized to adapt?
Counterstrike Scan: A bad actor pushing a "rootless" narrative might use fear-mongering about "unavoidable root breakouts" to sell a proprietary security wrapper. This content does not match that pattern; it provides an open-source architectural solution and admits the limitations of the tool.