Running Kubernetes nodes without root privileges is no longer a niche concern limited to shared HPC clusters. Kubernetes 1.37, released in August 2026, promoted the KubeletInUserNamespace feature to Beta, letting kubelet itself run inside a Linux user namespace. K3s, meanwhile, has shipped its own Rootless Mode for years. If you're evaluating K3s rootless for production, you need to understand how these two approaches actually differ.
1. What Changed in Kubernetes 1.37 — KubeletInUserNamespace Goes Beta
According to the official Kubernetes release page, v1.37 "Garhwal" ships 67 enhancements, 19 of which carry security implications. Among them, the Beta graduation of KubeletInUserNamespace — which lets kubelet and other node components run as a non-root user — stands out.
The feature's roots go back to 2018, starting as a proof of concept in the Usernetes project. It reached Alpha in v1.22 back in 2021, meaning it took a full five years to reach the Beta milestone. The official Kubernetes blog explains that this feature allows core node components — kubelet, CRI and OCI runtimes, CNI plugins, and kube-proxy — to run without root privileges on the host, using a Linux user namespace.
Enabling it requires several prerequisites: Cgroup v2 support, a systemd user session, and user entries in /etc/subuid and /etc/subgid. Because manual setup is involved, the most common path today is running it through kind, minikube, or Rootless Docker/Podman rather than configuring it by hand.
2. K3s Was Rootless Long Before This — But the Mechanism Is Different
K3s rootless isn't a new idea prompted by Kubernetes 1.37 — it existed well before the upstream feature reached Beta. The official K3s documentation describes Rootless Mode as a way to "run K3s servers as an unprivileged user, so as to protect the real root on the host from potential container-breakout attacks."
The mechanism, though, is substantially different from the Kubernetes 1.37 approach. K3s Rootless Mode puts the entire server process — not just kubelet, but containerd and the networking stack too — inside a user namespace, using RootlessKit and slirp4netns to bridge communication between the host and the namespace.
The limitations are significant. K3s Rootless Mode only supports pure Cgroup v2; Cgroup v1 or hybrid configurations will fail to start. It also doesn't support multi-node clusters — it's limited to a single process on a single node. That constraint is likely one reason the feature has remained experimental for so long.
3. What's Actually Different Between the Two Rootless Approaches
The differences boil down to three points.
Scope
- K3s Rootless Mode: Puts the entire server (including containerd and networking) inside a user namespace
- KubeletInUserNamespace: Puts individual node components — kubelet, CRI, CNI, kube-proxy — inside a user namespace
Dependency on External Tools
K3s's implementation depends on external tools, RootlessKit and slirp4netns. By contrast, the KEP-2033 design takes a more minimal approach, adding only small patches to kubelet and kube-proxy (to ignore certain sysctl and rlimit errors) and building the capability directly into Kubernetes itself.
The Security Payoff Is the Same
Different mechanisms, same goal. As the ThoughtWorks Technology Radar puts it, the core value of going rootless is that it "reduces the attack surface and avoids whole classes of security problems" tied to privilege escalation out of a container. Sysdig's analysis similarly notes that enabling KubeletInUserNamespace by default "significantly reduces the blast radius of container escape attacks."
4. Which One Should You Use for Multi-Tenant or Air-Gapped Environments?
The practical decision rule is straightforward. If your production workloads require cgroup-based resource limits, K3s Rootless Mode isn't an option today — it simply doesn't support cgroups. In that case, you're either watching Kubernetes 1.37's kubelet-in-userns approach mature (it's still Beta, so treat it as a test-environment feature for now) or sticking with standard root execution.
On the other hand, for test environments, lightweight edge workloads, or shared-host scenarios where multi-tenancy and root isolation matter more than strict resource guarantees, K3s Rootless Mode is a practical option today. InfoQ's coverage frames v1.37 as a release built around "stability, security, and AI/ML workload optimization" — and rootless support fits squarely into that push toward environments with strict data sovereignty or compliance requirements.
Kubo, a managed platform built on K3s, is well positioned to benefit from this kind of node-level security hardening. For environments where data can't leave the premises, an Kubo On-Premise deployment with an air-gapped K3s cluster is a realistic way to keep shrinking the per-node attack surface over time.
Conclusion
With KubeletInUserNamespace reaching Beta in Kubernetes 1.37, "rootless" has moved from an experimental side project toward a standard Kubernetes capability. But K3s's own Rootless Mode has different design goals and different constraints, so it would be premature to call it obsolete. Both are still evolving technologies, and the right move is to pick whichever fits your requirements rather than assuming one has replaced the other.
If you want to adopt serious Kubernetes security features without the cost and complexity of EKS or AKS, building on a lightweight K3s foundation is the fastest path there. Kubo keeps pace with security updates like this one while staying cost-efficient — see the pricing plans for details. If you'd like to talk through node-level security design for your own cluster, feel free to get in touch.