# Kubernetes v1.36: User Namespaces in Kubernetes are finally GA

DevFeed: [Kubernetes v1.36: User Namespaces in Kubernetes are finally GA](<https://devfeed.tech/articles/kubernetes-v1-36-user-namespaces-in-kubernetes-are-finally-ga-4538.md>)

Original publisher: [Read original article](<https://kubernetes.io/blog/2026/04/23/kubernetes-v1-36-userns-ga/>)

Author: Rodrigo Campos Catelin; Giuseppe Scrivano

Published: 2026-04-23T18:35:00Z

Content type: article

Language: en

Sources: [Kubernetes Blog](<https://devfeed.tech/sources/kubernetes-blog.md>)

Topics: [Kubernetes](<https://devfeed.tech/topics/kubernetes.md>), [Linux](<https://devfeed.tech/topics/linux.md>), [mount](<https://devfeed.tech/topics/mount.md>), [Security](<https://devfeed.tech/topics/security.md>), [Containers](<https://devfeed.tech/topics/containers.md>), [vulnerability](<https://devfeed.tech/topics/vulnerability.md>)

Tags: [containers](<https://devfeed.tech/tags/containers.md>), [kubernetes](<https://devfeed.tech/tags/kubernetes.md>), [linux](<https://devfeed.tech/tags/linux.md>), [mount](<https://devfeed.tech/tags/mount.md>), [performance](<https://devfeed.tech/tags/performance.md>), [process](<https://devfeed.tech/tags/process.md>), [security](<https://devfeed.tech/tags/security.md>), [startup](<https://devfeed.tech/tags/startup.md>), [vulnerability](<https://devfeed.tech/tags/vulnerability.md>)

## AI overview

Kubernetes v1.36 brings User Namespaces to General Availability, enabling rootless security isolation for workloads. The Linux-only feature confines container privileges to the user namespace, while ID-mapped mounts translate ownership at mount time without rewriting files or incurring expensive recursive ownership changes.

## Source excerpt

After several years of development, User Namespaces support in Kubernetes reached General Availability (GA) with the v1.36 release. This is a Linux-only feature. For those of us working on low level container runtimes and rootless technologies, this has been a long awaited milestone. We finally reached the point where "rootless" security isolation can be used for Kubernetes workloads. This feature also enables a critical pattern: running workloads with privileges and still being confined in the user namespace. When hostUsers: false is set, capabilities like CAP_NET_ADMIN become namespaced, meaning they grant administrative power over container local resources without affecting the host. This effectively enables new use cases that were not possible before without running a fully privileged container. The Problem with UID 0 A process running as root inside a container is also seen from the kernel as root on the host. If an attacker manages to break out of the container, whether through a kernel vulnerability or a misconfigured mount, they are root on the host. While there are many security measures in place for running containers, these measures don't change the underlying identity of the process, it still has some "parts" of root. The engine: ID-mapped mounts The road to GA wasn't just about the Kubernetes API; it was about making the kernel work for us. In the early stages, one of the biggest blockers was volume ownership. If you mapped a container to a high UID range, the Kubelet had to recursively chown every file in the attached volume so the container could read/write them. For large volumes, this was such an expensive operation that destroyed startup performance. The key enabler was ID-mapped mounts (introduced in Linux 5.12 and refined in later versions). Instead of rewriting file ownership on disk, the kernel remaps it at mount time. When a volume is mounted into a Pod with User Namespaces enabled, the kernel performs a transparent translation of the UIDs (us