Kubernetes v1.37 moves KubeletInUserNamespace, also known as rootless mode, to Beta. The feature lets node components such as the kubelet, container runtime interface (CRI), OCI runtime, and CNI components run as a non-root user inside a Linux user namespace.
That gives platform teams a supported path toward reducing host-level privileges on Kubernetes nodes. It is not, however, a universal drop-in replacement for rootful operation. Rootless nodes require cgroup v2, compatible runtime and networking components, specific host preparation, and careful validation of storage and port behavior.
What changed in Kubernetes 1.37
Kubernetes’ feature-gate reference lists KubeletInUserNamespace as a Beta feature in v1.37 and enabled by default. The feature was introduced as Alpha in v1.22. The official rootless-node documentation also identifies v1.37 as the Beta release.
In practical terms, Kubernetes node services can operate within a user namespace where the process has a non-root identity from the host’s perspective while retaining the namespace-specific permissions needed to perform supported operations. The design is intended to reduce the potential impact of problems affecting node components or container isolation by limiting their direct host privileges.
Rootless mode should not be confused with pod-level user namespaces. Kubernetes documents both capabilities, but they address different layers: KubeletInUserNamespace concerns the node components and their execution environment, while pod user namespaces concern workload containers.
Host prerequisites are substantial
Rootless node operation is limited to Linux environments with user-namespace support. The most important platform requirement is cgroup v2; cgroup v1 is not supported for this feature.
Administrators also need a systemd user session, delegated writable cgroups where applicable, suitable sysctl configuration, and subordinate user and group ID ranges in /etc/subuid and /etc/subgid. Required kubelet, CNI, and runtime storage paths must be writable within the relevant namespace.
The KubeletInUserNamespace design record recommends Linux kernel 5.2 or later and requires at least 4.15. It also recommends systemd 244 or later. These should be treated as documented design requirements and recommendations to validate against the target operating system rather than as a complete compatibility matrix for every Linux distribution.
Runtime and kubelet configuration
The Kubernetes documentation describes rootless operation with containerd and CRI-O. It also discusses rootless Docker, Rootless Podman, and rootless nerdctl environments used by projects such as kind and minikube.
The KEP lists containerd 1.4 or later and CRI-O 1.22 or later as required CRI versions. It lists runc 1.0-rc91 or later as required, runc 1.0-rc93 or later as recommended, and identifies crun as supported by the design. Actual operation still depends on the complete host and runtime combination.
A documented kubelet configuration uses the following settings:
KubeletInUserNamespace: true
cgroupDriver: cgroupfsThe documentation generally uses cgroupfs unless another systemd instance is available inside the namespace. The feature gate also allows the kubelet to ignore certain sysctl-setting errors and /dev/kmsg access errors that can occur inside a user namespace.
Feature gates can be configured through component arguments or configuration files. For kubeadm clusters, the supplied Kubernetes guidance describes component-specific changes, including kubelet configuration, control-plane manifests, and the kube-proxy ConfigMap, followed by restarts or rollouts. That guidance does not amount to a complete rootful-to-rootless migration procedure, so operators should not assume that enabling the feature creates a seamless in-place conversion path.
Networking and storage need validation
Rootless mode places important constraints on networking. The node component’s network namespace must have a usable non-loopback interface. The documentation identifies slirp4netns, VPNKit, and lxc-user-nic as possible mechanisms for providing networking, while regular CNI plugins can configure pod network namespaces.
Flannel using VXLAN is documented as a known-working example for multi-node networking. That is not a complete CNI support list: the documentation warns that some CNI plugins may not work, and there is no exhaustive compatibility matrix covering every plugin and host configuration.
kube-proxy also needs special handling. Rootless kube-proxy operation requires the documented conntrack settings to skip several unsupported sysctl updates, and the documentation specifies iptables or userspace mode.
Storage support is similarly limited. Local volumes, hostPath, emptyDir, configMap, secret, and downwardAPI volumes are identified as known to work. Most non-local volume drivers, including NFS and iSCSI, are documented as not working in this mode.
Port exposure and host-resource behavior also require workload-specific testing. Rootless operation restricts some privileged operations, devices, host resources, and node-level behaviors, so a workload that operates correctly on a rootful node may not behave the same way in a rootless environment.
Security benefits and limits
The primary security motivation is host protection. If a node component or container-breakout vulnerability were to affect a process running in the node environment, running that process without root privileges inside a user namespace can reduce its direct authority over the host.
That is a reduction in privilege, not an absolute security guarantee. The KEP warns that Linux user-namespace escape vulnerabilities remain a risk. It also identifies additional trade-offs, including operational complexity, reliance on third-party components, networking limitations, and possible CPU or memory overhead from user-mode networking implementations.
Organizations requiring stronger isolation for untrusted workloads may need additional sandboxing. The KEP specifically identifies technologies such as gVisor as an option for relevant scenarios. Rootless mode should therefore be evaluated as one layer of an isolation strategy, not as sufficient protection for every form of real multi-tenancy.
What you should do
- Inventory the target nodes. Confirm Linux user-namespace support, cgroup v2, systemd user-session behavior, kernel and systemd versions, subordinate UID/GID ranges, required sysctls, and delegated writable cgroups.
- Validate the runtime stack. Check the CRI, OCI runtime, runtime storage paths, and the version requirements documented in the KubeletInUserNamespace KEP.
- Test networking and storage independently. Verify the selected CNI, kube-proxy mode, port exposure, and every volume driver used by representative workloads. Treat Flannel VXLAN as a known-working example, not evidence that other CNIs are compatible.
- Start outside production. Run representative workloads in a non-production cluster and check kubelet behavior, pod networking, service traffic, storage, devices, and host integration before considering broader deployment.
- Document the boundary. Make clear whether your design uses node-level rootless mode, pod-level user namespaces, or both. They are related but distinct features with different requirements and security behavior.
Availability and adoption caveats
KubeletInUserNamespace is available as a Beta feature in Kubernetes v1.37, with its feature gate enabled by default in that release. Administrators should still verify the effective configuration of each component rather than relying only on the default.
The available documentation does not provide a complete matrix for CNI plugins, CSI drivers, operating systems, filesystems, service managers, or cloud-managed Kubernetes offerings. It also does not provide a full procedure for converting an existing rootful node or cluster. For now, rootless mode is best approached as a carefully validated node architecture for environments that can satisfy its prerequisites and accept its networking and storage limitations.
