[{"data":1,"prerenderedAt":323},["ShallowReactive",2],{"blog-en-k3s-rootless-kubelet-user-namespace-k8s-137":3,"blog-related-en-k3s-rootless-kubelet-user-namespace-k8s-137":272,"blog-en-k3s-rootless-kubelet-user-namespace-k8s-137-alt":261},{"id":4,"title":5,"author":6,"body":7,"date":255,"description":256,"extension":257,"image":258,"locale":259,"meta":260,"navigation":261,"path":262,"seo":263,"stem":264,"tags":265,"__hash__":271},"blog\u002Fblog\u002Fen\u002Fk3s-rootless-kubelet-user-namespace-k8s-137.md","The Day KubeletInUserNamespace Went Beta: Is K3s Rootless Mode Now Obsolete?","Kubo Team",{"type":8,"value":9,"toc":241},"minimark",[10,19,24,31,45,60,77,81,87,96,104,111,115,121,124,129,144,148,156,160,175,179,185,192,201,215,219,222],[11,12,13,14,18],"p",{},"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 ",[15,16,17],"code",{},"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.",[20,21,23],"h2",{"id":22},"_1-what-changed-in-kubernetes-137-kubeletinusernamespace-goes-beta","1. What Changed in Kubernetes 1.37 — KubeletInUserNamespace Goes Beta",[11,25,26],{},[27,28],"img",{"alt":29,"src":30},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fen\u002Fk3s-rootless-kubelet-user-namespace-k8s-137\u002Fsection01.webp",[11,32,33,34,41,42,44],{},"According to the ",[35,36,40],"a",{"href":37,"rel":38},"https:\u002F\u002Fkubernetes.io\u002Freleases\u002F1.37\u002F",[39],"nofollow","official Kubernetes release page",", v1.37 \"Garhwal\" ships 67 enhancements, 19 of which carry security implications. Among them, the Beta graduation of ",[15,43,17],{}," — which lets kubelet and other node components run as a non-root user — stands out.",[11,46,47,48,53,54,59],{},"The feature's roots go back to 2018, ",[35,49,52],{"href":50,"rel":51},"https:\u002F\u002Fwww.k8s.dev\u002Fresources\u002Fkeps\u002F2033\u002F",[39],"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 ",[35,55,58],{"href":56,"rel":57},"https:\u002F\u002Fkubernetes.io\u002Fblog\u002F2026\u002F09\u002F04\u002Fkubernetes-v1-37-rootless-beta\u002F",[39],"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.",[11,61,62,63,68,69,72,73,76],{},"Enabling it requires ",[35,64,67],{"href":65,"rel":66},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Ftasks\u002Fadminister-cluster\u002Fkubelet-in-userns",[39],"several prerequisites",": Cgroup v2 support, a systemd user session, and user entries in ",[15,70,71],{},"\u002Fetc\u002Fsubuid"," and ",[15,74,75],{},"\u002Fetc\u002Fsubgid",". Because manual setup is involved, the most common path today is running it through kind, minikube, or Rootless Docker\u002FPodman rather than configuring it by hand.",[20,78,80],{"id":79},"_2-k3s-was-rootless-long-before-this-but-the-mechanism-is-different","2. K3s Was Rootless Long Before This — But the Mechanism Is Different",[11,82,83],{},[27,84],{"alt":85,"src":86},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fen\u002Fk3s-rootless-kubelet-user-namespace-k8s-137\u002Fsection02.webp",[11,88,89,90,95],{},"K3s rootless isn't a new idea prompted by Kubernetes 1.37 — it existed well before the upstream feature reached Beta. The ",[35,91,94],{"href":92,"rel":93},"https:\u002F\u002Fdocs.k3s.io\u002Fadvanced",[39],"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.\"",[11,97,98,99,103],{},"The mechanism, though, is substantially different from the Kubernetes 1.37 approach. K3s Rootless Mode puts the ",[100,101,102],"strong",{},"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.",[11,105,106,107,110],{},"The limitations are significant. K3s Rootless Mode only supports ",[100,108,109],{},"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.",[20,112,114],{"id":113},"_3-whats-actually-different-between-the-two-rootless-approaches","3. What's Actually Different Between the Two Rootless Approaches",[11,116,117],{},[27,118],{"alt":119,"src":120},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fen\u002Fk3s-rootless-kubelet-user-namespace-k8s-137\u002Fsection03.webp",[11,122,123],{},"The differences boil down to three points.",[125,126,128],"h3",{"id":127},"scope","Scope",[130,131,132,139],"ul",{},[133,134,135,138],"li",{},[100,136,137],{},"K3s Rootless Mode",": Puts the entire server (including containerd and networking) inside a user namespace",[133,140,141,143],{},[100,142,17],{},": Puts individual node components — kubelet, CRI, CNI, kube-proxy — inside a user namespace",[125,145,147],{"id":146},"dependency-on-external-tools","Dependency on External Tools",[11,149,150,151,155],{},"K3s's implementation depends on external tools, RootlessKit and slirp4netns. By contrast, ",[35,152,154],{"href":50,"rel":153},[39],"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.",[125,157,159],{"id":158},"the-security-payoff-is-the-same","The Security Payoff Is the Same",[11,161,162,163,168,169,174],{},"Different mechanisms, same goal. As the ",[35,164,167],{"href":165,"rel":166},"https:\u002F\u002Fwww.thoughtworks.com\u002Fen-au\u002Fradar\u002Fplatforms\u002Frootless-containers",[39],"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. ",[35,170,173],{"href":171,"rel":172},"https:\u002F\u002Fwww.sysdig.com\u002Fblog\u002Fkubernetes-1-37-new-security-features",[39],"Sysdig's analysis"," similarly notes that enabling KubeletInUserNamespace by default \"significantly reduces the blast radius of container escape attacks.\"",[20,176,178],{"id":177},"_4-which-one-should-you-use-for-multi-tenant-or-air-gapped-environments","4. Which One Should You Use for Multi-Tenant or Air-Gapped Environments?",[11,180,181],{},[27,182],{"alt":183,"src":184},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fen\u002Fk3s-rootless-kubelet-user-namespace-k8s-137\u002Fsection04.webp",[11,186,187,188,191],{},"The practical decision rule is straightforward. If your production workloads ",[100,189,190],{},"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.",[11,193,194,195,200],{},"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. ",[35,196,199],{"href":197,"rel":198},"https:\u002F\u002Finfoq.com\u002Fnews\u002F2026\u002F09\u002Fkubernetes-1-37",[39],"InfoQ's coverage"," frames v1.37 as a release built around \"stability, security, and AI\u002FML workload optimization\" — and rootless support fits squarely into that push toward environments with strict data sovereignty or compliance requirements.",[11,202,203,208,209,214],{},[35,204,207],{"href":205,"rel":206},"https:\u002F\u002Fkubo.hexabase.io\u002F",[39],"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 ",[35,210,213],{"href":211,"rel":212},"https:\u002F\u002Fwww.hexabase.com\u002Fproduct\u002Fkubo\u002Fon-premise",[39],"Kubo On-Premise"," deployment with an air-gapped K3s cluster is a realistic way to keep shrinking the per-node attack surface over time.",[20,216,218],{"id":217},"conclusion","Conclusion",[11,220,221],{},"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.",[11,223,224,225,228,229,234,235,240],{},"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. ",[35,226,207],{"href":205,"rel":227},[39]," keeps pace with security updates like this one while staying cost-efficient — see the ",[35,230,233],{"href":231,"rel":232},"https:\u002F\u002Fwww.hexabase.com\u002Fpricing\u002F",[39],"pricing plans"," for details. If you'd like to talk through node-level security design for your own cluster, feel free to ",[35,236,239],{"href":237,"rel":238},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[39],"get in touch",".",{"title":242,"searchDepth":243,"depth":243,"links":244},"",2,[245,246,247,253,254],{"id":22,"depth":243,"text":23},{"id":79,"depth":243,"text":80},{"id":113,"depth":243,"text":114,"children":248},[249,251,252],{"id":127,"depth":250,"text":128},3,{"id":146,"depth":250,"text":147},{"id":158,"depth":250,"text":159},{"id":177,"depth":243,"text":178},{"id":217,"depth":243,"text":218},"2026-10-28","Kubernetes 1.37 promoted KubeletInUserNamespace (Rootless Mode) to Beta. K3s has had its own Rootless Mode for years, but the mechanism is completely different. Here's how the two approaches compare and how to choose between them.","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fen\u002Fk3s-rootless-kubelet-user-namespace-k8s-137\u002Ftitle.webp","en",{},true,"\u002Fblog\u002Fen\u002Fk3s-rootless-kubelet-user-namespace-k8s-137",{"title":5,"description":256},"blog\u002Fen\u002Fk3s-rootless-kubelet-user-namespace-k8s-137",[266,267,268,269,270],"k3s","kubernetes","rootless","security","kubelet","TMzr0OyfZxM0ZbzvyhDAVESJhhimTz3F8N6exDcWr90",[273,282,291,299,307,315],{"path":274,"title":275,"description":276,"date":277,"tags":278},"\u002Fblog\u002Fen\u002Fk3s-k8s-default-serviceaccount-automount-rbac-multi-tenant","K3s and Kubernetes Share the Same Default ServiceAccount Trap. What Happens When You Leave Automount Enabled in a Multi-Tenant Cluster","Comparing k3s vs k8s doesn't change the default ServiceAccount automount trap. We cover the privilege-escalation risk in multi-tenant clusters, a real CVE, and a 4-layer defense.","2026-10-23",[266,267,279,280,281,269],"rbac","serviceaccount","multi-tenancy",{"path":283,"title":284,"description":285,"date":286,"tags":287},"\u002Fblog\u002Fen\u002Fk3s-pod-security-admission-restricted-servicelb-outage","We Enabled Restricted and ServiceLB Died: The K3s Pod Security Admission Gap No Generic Guide Mentions","Enabling the restricted Pod Security Admission profile on K3s following standard Kubernetes guides can silently kill ServiceLB. Here's why, backed by K3s's own CIS hardening guide, and how to roll it out safely.","2026-10-16",[266,267,288,289,290,269],"pod-security-admission","pod-security-standards","servicelb",{"path":292,"title":293,"description":294,"date":295,"tags":296},"\u002Fblog\u002Fen\u002Fk3s-zero-trust-kubectl-management-access","Stop Trusting Your Corporate VPN: 3 Steps to Make K3s Management Access Boundary-Free","Are you still designing K3s cluster management access around a corporate VPN? Learn 3 practical steps to secure kubectl and Rancher dashboard access with identity instead of network perimeter, plus the pitfall most teams hit when they implement zero trust.","2026-09-05",[266,267,297,269,298],"zero-trust","rancher",{"path":300,"title":301,"description":302,"date":303,"tags":304},"\u002Fblog\u002Fen\u002Fkubernetes-certificate-management-cert-manager-process-debt","The Cert Renewal Took One Line of Code and Two Months of Meetings: Why Kubernetes Certificate Management Is a Process Problem, Not a Technical One","Kubernetes certificate management is technically a matter of days. What actually takes time is the organizational process of getting sign-off. Here's how cert-manager automates the technical side, and how to design away the operational debt that remains.","2026-08-09",[266,267,305,306,269],"cert-manager","tls",{"path":308,"title":309,"description":310,"date":311,"tags":312},"\u002Fblog\u002Fen\u002Fai-agent-sandbox-kata-containers-kubernetes","AI Agent Code Isn't a \"Trusted Product\" Anymore. Kubernetes Sandbox Design Has an Answer","Code generated and executed by AI agents can no longer be treated as a trusted, reviewed product. This article explains the limits of container isolation and why Kata Containers' microVM isolation is becoming essential when designing AI agent sandboxes on Kubernetes.","2026-08-08",[266,267,313,314,269],"kata-containers","ai-agent",{"path":316,"title":317,"description":318,"date":319,"tags":320},"\u002Fblog\u002Fen\u002Fkubernetes-image-signing-sigstore-supply-chain","Anyone Can Rewrite an Image Tag. Why Kubernetes Needs Sigstore-Backed Signing to Prove Provenance","Container image signing explained: tags can be overwritten by anyone, and passing CI tests doesn't guarantee the image running in production is the one you built. Learn how Sigstore and Kyverno work together to reject unsigned images on Kubernetes\u002FK3s, integrated into a GitOps workflow.","2026-08-06",[266,267,321,322,269],"ci-cd","gitops",1793798726408]