Kubernetes 1.37 promotes rootless node components to beta

Kubernetes v1.37 promotes the KubeletInUserNamespace feature to beta. In this mode the node components—including kubelet, the CRI/OCI runtime, CNI plugins and kube-proxy—run as a non-root host user inside a Linux user namespace. The feature gate is enabled by default in 1.37, but enabling the gate alone does not convert an existing node: the surrounding user-namespace environment and compatible runtime/network/storage stack still have to be configured. Kubernetes exposes whether a node is running in this mode so operators can use labels, taints and scheduling policy around mixed clusters.

A compromised privileged node component normally has a path toward host-root authority. Moving the node stack into a user namespace reduces that blast radius and also makes Kubernetes practical in environments where host root is unavailable, such as shared HPC machines, developer laptops, nested clusters and some agent sandboxes. Beta status means the design is far more testable than an alpha experiment, but production adoption still depends on drivers and infrastructure that tolerate the altered privilege model.

KubeletInUserNamespace places kubelet and the supporting runtime/network node processes inside a Linux user namespace under a non-root host UID. This is distinct from simply setting a pod's securityContext to non-root.

Kubernetes 1.37 enables the feature gate by default. Existing clusters remain rootful unless operators explicitly create the required user-namespace environment and launch compatible node components inside it.

The node status exposes whether components are running in a user namespace, making it possible to label, taint or otherwise steer workloads based on the node's security model.

Some CNI and CSI implementations still assume host-root privileges or operations that do not map cleanly inside the user namespace. Teams need conformance and storage/network testing before standardizing the mode.