# Kubernetes 1.37 promotes rootless node components to beta

Kubernetes 1.37 moves KubeletInUserNamespace to beta, allowing kubelet, container runtimes, CNI plugins and kube-proxy to run as a non-root host user inside a Linux user namespace.

The security shift is deeper than running application containers as non-root: the node stack itself can now live inside a user namespace. The feature is enabled by default in 1.37, but clusters do not become rootless automatically and CNI/CSI compatibility still needs testing.

- Status: Active
- Published: 2026-09-06T14:37:05+12:00
- Updated: 2026-09-06T14:37:05+12:00
- Categories: Cloud & Infrastructure, Cloud Platforms, Deployment & DevOps
- Tags: container security, kubelet, Kubernetes, Linux user namespaces, rootless containers
- Canonical HTML: https://beyondthe.news/dossiers/kubernetes-1-37-rootless-node-components-beta-user-namespace

## What changed

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.

## Why it matters

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.

## The node stack, not only pods, can be rootless

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.

## Beta is enabled by default but migration is not automatic

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.

## Schedulers can distinguish rootless nodes

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.

## Drivers remain the practical compatibility boundary

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.

## Key details

- KubeletInUserNamespace is beta in Kubernetes 1.37.
- The feature gate is enabled by default in 1.37.
- Kubelet, CRI/OCI runtimes, CNI plugins and kube-proxy can run as a non-root host user in a Linux user namespace.
- Enabling the feature gate does not automatically make existing nodes rootless.
- Nodes expose whether they are running in a user namespace for policy/scheduling use.
- Kubernetes says its CI runs node conformance testing against rootless configurations.
- CNI and CSI compatibility remains workload/infrastructure dependent.

## Builder takeaways

- Treat rootless-node adoption as a node-image/runtime project, not a single feature-flag change.
- Build a compatibility matrix for your CNI, CSI, device plugins and monitoring/security agents before production rollout.
- Use labels or taints to keep workloads that require conventional host privileges off rootless nodes.
- Combine node-level rootless operation with pod user namespaces such as `hostUsers: false` where nested isolation is useful.
- Measure operational tooling too: backup, debugging and node-repair workflows may assume host root even when ordinary workload execution does not.

## What to watch

- CNI and CSI projects explicitly certifying support for rootless Kubernetes nodes.
- Managed Kubernetes providers exposing KubeletInUserNamespace as a supported node option.
- Movement from beta to GA and any changes to the external user-namespace setup requirements.
- Security research measuring the practical reduction in node-escape impact.

## Uncertainties

- Compatibility varies across networking, storage and device integrations.
- Beta status does not imply every managed cluster or Linux distribution supports the required setup.
- Rootless node components reduce host privilege but do not remove Kubernetes control-plane, kernel or container-runtime attack surfaces.

## Sources

- [Kubernetes v1.37: Rootless node components graduate to beta](https://kubernetes.io/blog/2026/09/04/kubernetes-v1-37-rootless-beta/) — Kubernetes · primary project announcement · 2026-09-04T00:00:00+12:00. Primary description of beta status, architecture, use cases and compatibility caveats.