Kubernetes User Namespaces Reach GA

Kubernetes user namespaces finally reached stable status in Kubernetes v1.36. For SRE and platform teams, the big win is simple: a process can run as root inside the pod while mapping to an unprivileged user on the host.

What Is New in v1.36?

The feature is now enabled by default and no longer sits behind a long beta story. According to the official Kubernetes v1.36 announcement, this makes it practical to run workloads that expect UID 0 while sharply reducing what a breakout can do on the node.

A few details matter for operators:

• hostUsers: false opts a pod into user namespaces
• container capabilities are namespaced, so powers like CAP_NET_ADMIN stay local to the pod
• ID-mapped mounts avoid slow recursive chown operations on volumes
• Kubernetes assigns non-overlapping UID and GID mappings per pod on the node

That last point is especially useful in multi-tenant environments because one compromised pod has a much harder time interfering with another.

Why Platform Teams Should Care

This is one of the more practical Kubernetes security upgrades in recent releases. Many images still assume they can start as root. Rebuilding all of them for strict non-root execution takes time, testing, and political capital. User namespaces give teams a middle path.

Inside the container, common setup steps still work. On the host, that same process no longer has real root identity. This reduces exposure to container escape bugs, risky mounts, and accidental privilege bleed.

Installation

You need Linux support for ID-mapped mounts plus a compatible runtime stack. The Kubernetes docs call out Linux 6.3 or newer as the practical baseline for common filesystems such as tmpfs, ext4, xfs, and overlayfs.

Runtime support should also be current:

# examples from the Kubernetes docs
containerd 2.0+
crio 1.25+
runc 1.2+ or crun 1.9+

Usage

The Pod spec change is small:

apiVersion: v1
kind: Pod
metadata:
  name: isolated-workload
spec:
  hostUsers: false
  containers:
    - name: app
      image: fedora:42
      securityContext:
        runAsUser: 0

This lets the workload behave like root inside the pod while remaining unprivileged on the host.

Operational Tips

Start with lower-risk workloads that still want UID 0, such as legacy agents, build helpers, or network tools. Validate storage behavior first, especially if your pods mount persistent volumes or hostPath. It is also smart to confirm your container runtime version before enabling this cluster wide.

Conclusion

Kubernetes user namespaces reaching GA is a meaningful security milestone, not just a checkbox feature. It gives operators a realistic way to shrink host risk without forcing every workload rewrite on day one.

If you are building reliable, AI-assisted operations, Akmatori helps teams automate infrastructure workflows and incident response. Backed by Gcore, we are building tools for modern SRE and platform teams.