OpsCanary
kubernetessecurityPractitioner

KubeletInUserNamespace: Elevating Security in Kubernetes v1.37

5 min read Kubernetes BlogSep 4, 2026Reviewed for accuracy
Share
PractitionerHands-on experience recommended

KubeletInUserNamespace exists to enhance security within your Kubernetes clusters. By allowing all node components—like the kubelet, CRI and OCI runtimes, CNI plugins, and kube-proxy—to operate as non-root users, it confines potential damage to a limited user account. This is crucial in a world where vulnerabilities can lead to severe breaches if a root user is compromised.

The mechanism behind this feature leverages Linux kernel user namespaces. It maps a host-level non-root user (for example, UID 1000) to a fake root user within the namespace. This fake root has sufficient privileges to perform essential tasks, such as mounting volumes, creating cgroups, and configuring network namespaces for pods. With the KubeletInUserNamespace feature gate enabled by default, you can ignore permission errors related to sysctl values and kernel message watching, making it easier to manage your clusters.

In production, you should be aware of a couple of important caveats. First, while this feature enhances security, it does not mitigate vulnerabilities in the kernel itself. Additionally, user namespaces must be created outside of Kubernetes, which can add complexity to your setup. Kubernetes v1.37 marks a pivotal moment in adopting this feature, which was initially introduced as an alpha in v1.22. Make sure to test this thoroughly in your environments before rolling it out widely.

Key takeaways

  • Enable KubeletInUserNamespace to run node components as non-root users.
  • Utilize Linux kernel user namespaces to limit privileges effectively.
  • Remember that user namespaces do not protect against kernel vulnerabilities.
  • Create user namespaces outside of Kubernetes for proper functionality.

Why it matters

This feature significantly reduces the attack surface of your Kubernetes nodes, enhancing overall cluster security. Running components as non-root users limits the potential impact of any security breach.

Code examples

Bash
# Example using Docker
dockerd-rootless-setuptool.sh install
kind create cluster
Bash
dockerd-rootless-setuptool.sh install
minikube start --driver=docker

When NOT to use this

The official docs don't call out specific anti-patterns here. Use your judgment based on your scale and requirements.

Want the complete reference?

Read official docs

Test what you just learned

Quiz questions written from this article

Take the quiz →
Linux FoundationSponsor

Industry-standard certifications built by the people behind Linux and Kubernetes. Earn the CKA — the gold standard Kubernetes administrator cert. OpsCanary readers get 30% off year-round with code OPSCANARY3.

Get CKA certified →

Get the daily digest

One email. 5 articles. Every morning.

No spam. Unsubscribe anytime.