Kubernetes v1.37: KubeletInUserNamespace (Rootless Mode) Moves to Beta

Node‑level components (kubelet, CRI, OCI runtimes, CNI plugins, kube‑proxy) have repeatedly been the entry point for container‑breakout attacks. When these binaries run as the host’s root user, a single exploit can grant an attacker full control over the underlying operating system.

Representative breakout vulnerabilities

• CVE‑2022‑0811 (cr8escape): CRI‑O accepted arbitrary sysctl settings such as kernel.core_pattern, enabling code execution as root on the host.
• CVE‑2023‑27561: A race in runc allowed a volume mount to bypass masked paths, exposing the host’s /proc filesystem.
• CVE‑2024‑10220: The kubelet could be coerced into running commands as root via malicious gitRepo volume definitions.
• CVE‑2025‑31133: runc could bind‑mount attacker‑controlled paths and write to privileged procfs entries such as /proc/sysrq-trigger and /proc/sys/kernel/core_pattern.
• CVE‑2026‑53488: containerd executed arbitrary host commands when processing crafted image labels.

How rootless (user‑namespace) mode mitigates impact

When the KubeletInUserNamespace feature gate is enabled, the Linux kernel creates a user namespace that maps a non‑root host UID (e.g., 1000) to UID 0 inside the namespace. The “root” privileges are therefore confined to the namespace boundary:

• System‑wide resources such as the boot loader, kernel modules, and firmware remain immutable because the namespace does not grant true root capabilities.
• Any exploit that succeeds against a node component can only affect files and devices owned by the mapped non‑root UID, limiting persistence and lateral movement.
• Standard hardening layers—seccomp profiles, AppArmor/SELinux policies, and read‑only root filesystems—remain effective and are not bypassed by the namespace.

Practical example

Using kind with rootless Docker:

# Prepare a rootless Docker environment
dockerd-rootless-setuptool.sh install

# Create a rootless cluster
kind create cluster --config kind-rootless.yaml

After cluster creation, kubectl get nodes -o yaml shows runningInUserNamespace: true. Scheduling workloads that require true host root (e.g., certain CNI installers) can be prevented by adding a node label or taint based on this property.

Compliance relevance

Running node components in a user namespace aligns with security frameworks such as SOC 2, ISO 27001, NIST SP 800‑53, and OWASP ASVS by reducing the attack surface and ensuring that privileged operations are auditable and isolated. It supports the principle of least privilege, a core requirement across these standards.

A Linux user namespace creates an isolated mapping between the host’s user identifiers and a set of identifiers that appear as root (UID 0) inside the namespace. When a non‑root host user such as UID 1000 creates the namespace, the kernel translates UID 0 in the namespace back to UID 1000 on the host. This “fake root” has full privileges only within the namespace boundaries; any operation that would normally require real root on the host is confined to the namespace’s view of the system.

Because the node components (kubelet, CRI, OCI runtimes, CNI plugins, and kube‑proxy) run inside this namespace, they can perform the actions required for Kubernetes operation without possessing host‑level root:

• Mounting volumes: The fake root can invoke mount syscalls, allowing the kubelet to attach host paths or CSI‑provided block devices to pod filesystems.
• Creating cgroups: Writable cgroup hierarchies are available to the non‑root user, enabling resource isolation for containers.
• Configuring network namespaces: The node can set up per‑pod network namespaces, assign interfaces, and apply IP address configuration required by the CNI layer.

Despite these capabilities, several compatibility caveats remain:

• Some CNI plugins expect unrestricted access to /proc/sys/net or to iptables, which may be blocked for a non‑root user.
• CSI drivers that perform privileged host‑side operations (e.g., writing to /dev/kmsg or adjusting kernel sysctls such as vm.overcommit_memory) can fail with permission errors.
• Features that rely on kernel messages via /dev/kmsg are ignored by the kubelet when running in a user namespace, as described by the KubeletInUserNamespace feature gate.

Practical setup example using kind with a rootless Docker runtime:

# Prepare a rootless Docker environment
dockerd-rootless-setuptool.sh install

# Create a rootless cluster
kind create cluster

After the cluster is up, the node status reports the runningInUserNamespace property. Administrators can use this property to label or taint nodes, preventing workloads that require true root privileges (such as certain CNI installers) from being scheduled on rootless nodes.

In summary, the user‑namespace mapping provides a confined root environment sufficient for mounting, cgroup creation, and network configuration, but engineers must verify driver compatibility and adjust scheduling policies accordingly.

The KubeletInUserNamespace feature gate graduated to beta in Kubernetes v1.37 and is now enabled by default. Enabling the gate does not automatically place a node in a user namespace; it merely allows the kubelet to ignore permission errors that arise when it runs without full root privileges. Existing “rootful” clusters therefore continue to operate unchanged unless the administrator explicitly creates a user namespace for the node components.

When a node runs inside a user namespace, the API server adds a boolean field runningInUserNamespace to the node’s status. The field is visible with:

kubectl get nodes -o yaml | grep runningInUserNamespace

Cluster operators can use this property to label or taint nodes, preventing workloads that require real root privileges (e.g., certain CNI installers) from being scheduled on root‑less nodes.

Practical setup with common local clusters

• kind
  • Install rootless Docker (or rootless nerdctl/Podman) with dockerd-rootless-setuptool.sh install.
  • Create a rootless cluster: kind create cluster.
  • Verify the node property: kubectl get node -o yaml | grep runningInUserNamespace.
• minikube
  • Prepare rootless Docker as above.
  • Start a rootless cluster: minikube start --driver=docker.
  • Check the node status with the same kubectl command.
• Usernetes
  • Install rootless Docker/Podman.
  • Run usernetes up to provision one or more rootless nodes connected via VXLAN (Flannel CNI).
  • Optionally enable the experimental Kubernetes‑in‑Kubernetes mode for nested testing.
• k3s
  • Rootless k3s does not depend on an external runtime; install it directly from the k3s binary.
  • Start with k3s server --rootless (or the equivalent flag documented by k3s).
  • Validate the node property as described earlier.

In all cases, the node’s ability to mount volumes, create cgroups, and configure pod network namespaces is retained because the user namespace maps a host UID (e.g., 1000) to UID 0 inside the namespace. Administrators should still apply standard hardening—seccomp profiles, restricted sysctls, and appropriate RBAC—since user namespaces do not mitigate kernel‑level vulnerabilities.

Running Kubernetes node components in a user namespace (root‑less mode) requires a Linux kernel that supports the necessary namespace extensions. Kernel v6.3 introduced id‑mapped tmpfs, which allows the fake root UID 0 inside the namespace to map to a non‑privileged host UID without exposing host‑wide resources. Without this kernel feature, volume mounts and temporary files created by the kubelet, CRI, and CNI plugins would inherit host‑level permissions, breaking the isolation guarantees of root‑less clusters.

The container runtime must also understand the altered cgroup layout. containerd v2.1 added support for writable cgroups, enabling unprivileged containers to create and manage their own cgroup hierarchies. This capability is required for the kubelet to perform pod‑level resource accounting when the node itself runs without root privileges.

Potential incompatibilities

• CNI plugins that attempt to write directly to /proc/sys/net/bridge/bridge-nf-call-iptables or modify host‑level iptables rules may fail because those sysctls are inaccessible from a user namespace.
• CSI drivers that rely on privileged init containers to perform host‑path provisioning (e.g., mounting block devices) can encounter permission errors when the node lacks root capabilities.
• Plugins that expect writable cgroup v1 hierarchies without the writable_cgroup flag will not start under containerd v2.1’s default configuration.

Hardening recommendations

User namespaces mitigate container‑breakout vulnerabilities, but they do not protect against kernel‑level exploits. Combine them with additional layers such as seccomp, AppArmor/SELinux, and strict pod security standards (e.g., OWASP Kubernetes Hardening Guide).

• Define a RuntimeClass that references a seccomp profile denying ptrace, mount, and reboot system calls.
• Enable securityContext.seccompProfile.type: RuntimeDefault on all pod specs.
• Apply PodSecurityPolicy or the newer PodSecurityAdmission to enforce runAsNonRoot and readOnlyRootFilesystem.
• Label nodes that run in a user namespace (e.g., node.kubernetes.io/rootless=true) and use node selectors to keep workloads that require privileged operations off those nodes.

Example: a root‑less cluster created with kind using Docker’s rootless mode can be started with the following command, which ensures the required kernel and containerd versions are present and applies a default seccomp profile:

dockerd-rootless-setuptool.sh install
kind create cluster --config=kind-rootless.yaml
kubectl label node $(kubectl get nodes -o name) node.kubernetes.io/rootless=true