Kubernetes 1.37 Rootless Nodes: KubeletInUserNamespace Beta Guide

Kubernetes 1.37 promotes KubeletInUserNamespace to beta. It allows kubelet, the container runtime, CNI plugins, kube-proxy, and other node components to run as a non-root host user inside a Linux user namespace.

That reduces the host-level impact of some container-breakout or node-component vulnerabilities. It does not make the kernel trusted by default, remove the need for seccomp, or guarantee compatibility with every CNI and CSI driver.

Rootless Nodes Are Not the Same as Rootless Pods

Two Kubernetes features use user namespaces at different layers:

Pod user namespaces reached general availability through UserNamespacesSupport in Kubernetes 1.36. The two features can be combined, including for nested Kubernetes clusters, but enabling one does not automatically enable the other.

What Beta Changes in Kubernetes 1.37

The feature gate is enabled by default, but existing clusters do not suddenly become rootless. The kubelet must already be launched inside a user namespace prepared outside Kubernetes.

Kubernetes 1.37 also reports whether a node is running in a user namespace through the node status property runningInUserNamespace. That makes it possible to audit nodes and build scheduling controls for workloads that require real host-root behavior.

Inspect the property across nodes:

kubectl get nodes -o json | jq -r '
  .items[] |
  [.metadata.name, (.status.nodeInfo.runningInUserNamespace // false)] |
  @tsv
'

Before automating labels from this signal, confirm the exact API output on your Kubernetes build and protect the automation's credentials with least privilege.

How the Isolation Works

A Linux user namespace maps an unprivileged host user, such as UID 1000, to UID 0 inside the namespace. Processes can perform many root-like operations inside that namespace without receiving unrestricted root privileges on the host.

For node components, that mapped privilege can be enough to manage namespaced mounts, cgroups, and Pod network namespaces. Kubernetes relaxes expected permission failures for a small set of host operations, including some sysctl writes and access to /dev/kmsg.

The boundary does not protect against kernel vulnerabilities reachable from the namespace. Continue to use patched kernels, minimal host packages, seccomp, Linux Security Modules, capability restrictions, and runtime hardening.

Good Evaluation Use Cases

Rootless nodes are especially interesting for:

• developer laptops where a local cluster should not rewrite host VPN or firewall state;
• shared HPC or lab machines where users cannot receive host root;
• isolated AI coding-agent sandboxes;
• Kubernetes-in-Kubernetes test environments;
• production node pools that run compatible, lower-trust workloads.

Do not begin with storage-heavy or networking-specialized production workloads. CNI installers, CSI drivers, device plugins, privileged DaemonSets, and host-level observability agents may depend on real host privileges.

Build a Compatibility Matrix

Test each node-level dependency, not only a sample application:

The upstream post notes that containerd 2.1 added writable cgroup support and Linux 6.3 added idmapped tmpfs support. Treat those as useful milestones, not a blanket compatibility guarantee for your distribution.

Isolate Rootless Workloads with Labels and Taints

After validating a node pool, label it explicitly:

kubectl label node worker-rootless-01 node.devopsboys.com/rootless=true
kubectl taint node worker-rootless-01 node.devopsboys.com/rootless=true:NoSchedule

Only workloads reviewed for the pool should tolerate the taint and select the label. Keep root-required DaemonSets off the pool unless their maintainers document compatibility.

Do not rely on a manually applied label forever. Reconcile it from observed node status or your provisioning source so a rebuilt rootful node cannot silently inherit rootless workload placement.

Safe Rollout Plan

1. Create a disposable node with the target kernel, runtime, CNI, and CSI versions.
2. Run Kubernetes node conformance and your platform smoke tests.
3. Test DNS, Services, NetworkPolicy, volumes, logs, metrics, and node upgrades.
4. Add one isolated non-production node pool with labels and taints.
5. Monitor permission errors and degraded DaemonSets.
6. Document an escape path back to a rootful pool before production use.

Rootless mode narrows a valuable privilege boundary, but beta is the right time to validate assumptions—not to remove the rest of the node security model.

Plan the feature alongside the Kubernetes 1.37 upgrade guide, especially when your node pools use custom CNI, CSI, or observability agents.

Sources

• Kubernetes Blog: KubeletInUserNamespace graduates to beta
• Kubernetes Docs: Running Kubernetes node components as a non-root user
• KEP-2033: Kubelet in user namespace