Kubernetes 1.36 stabilizes pod user namespaces

Kubernetes 1.36 makes support for user namespaces in pods stable. A process can have root privileges inside its container's user namespace while mapping to an unprivileged identity on the host. This changes the relationship between an application's internal user model and the authority that its processes have outside the pod.

I regard this as a useful improvement to a system I have used for eight years. My attachment to Kubernetes comes from its reconciliation model and the API machinery that makes operational policy declarative. My experience with Talos clusters, Cilium, and GitOps also makes me interested in which security properties the declared workload actually requests. Stability gives this setting a stronger adoption basis, but the pod still has to opt in and the node must support it.

The release also advances workload-aware scheduling through alpha work on grouped pods. That is a separate placement concern. I would evaluate user namespaces as an isolation change with its own compatibility checks, independent of whether a workload needs coordinated group scheduling. The security property here concerns user identity and capabilities on a node. I would give the isolation change a distinct rollout decision so that a scheduling experiment does not obscure a runtime compatibility failure. Each change needs evidence tied to the mechanism it introduces.

A container user and a host user can differ

The user-namespace documentation available by release day describes the mapping. The kubelet chooses host user and group IDs for each participating pod. It guarantees different, non-overlapping mappings for pods on the same node. A user ID inside one pod therefore does not identify the same host user as that numeric ID inside another pod.

That distinction is particularly useful for an application that expects root inside its container. The application can retain that internal expectation while the host sees an unprivileged user. Capabilities have namespace scope as well. The documentation explains that CAP_SYS_MODULE does not allow such a pod to load kernel modules, and that CAP_SYS_ADMIN is limited to the user namespace.

I would describe the result as reducing the damage possible after compromise. I would not claim that enabling a user namespace proves that an application cannot escape or affect the node. The documented mechanism restricts identities and capabilities outside the namespace. A security review still needs to examine the resources and permissions made available to the workload.

The distinction also changes how I would inspect a process. The documentation suggests comparing the user visible through id inside the container with the identity visible through ps on the host. Those values differ because they belong to different mappings. An operating procedure that assumes those views must agree would misinterpret an intended result of the feature.

The workload opts in through hostUsers

A pod requests a separate user namespace by setting spec.hostUsers to false. For a controller that creates pods, this belongs in the pod template. The following is a configuration fragment showing its placement in a Deployment, with the rest of the workload specification omitted:

spec:
  template:
    spec:
      hostUsers: false

This fragment is not a complete Deployment. Its purpose is to identify the field that changes user-namespace behavior without implying that a particular application image or security context has been tested. I would make the first adoption change on a representative workload whose storage and host-access requirements are understood.

The existing security-context user fields keep their container meaning. The documentation states that runAsUser, runAsGroup, and fsGroup refer to users inside the container. An operator should therefore avoid substituting the mapped host ID into those fields. The kubelet and runtime manage the mapping to host identities.

This is also why user namespaces do not require changing volume ownership merely to toggle the feature. The documentation says the pod's internal user settings determine access to volumes it can mount. It describes enabling or disabling user namespaces without changing the volume's file ownership. I would still verify the application's actual read and write behavior, because filesystem support and the set of mountable volumes remain separate prerequisites.

I would keep the intended security property in the configuration review. If an application needs root only within its own environment, the review should say that. If it depends on access to host resources, that dependency needs examination before selecting user namespaces as a compatible isolation setting. A field added to every template without that assessment would obscure the workloads that need a different treatment.

Node support includes the filesystems

The release-day documentation identifies this as a Linux-only feature. It requires idmapped mount support for the filesystem holding the kubelet's pod directory and for all filesystems used by the pod's volumes. That means checking the storage path as well as the container runtime. A node can satisfy one requirement while a mounted volume fails another.

The documentation gives Linux 6.3 as the practical minimum because that release added idmapped mount support for tmpfs. Kubernetes commonly uses tmpfs for Secrets and the default mounted service-account token. An application without a persistent volume can therefore still depend on the filesystem requirement. I would include projected and ephemeral data in the compatibility inventory.

Runtime support is required at both the CRI and OCI levels. The documented supported versions include containerd 2.0 or later and CRI-O 1.25 or later. At the OCI layer, it lists runc 1.2 or later and crun 1.9 or later, with crun 1.13 or later recommended. These are component prerequisites, so I would check what the node actually runs before drawing conclusions from the Kubernetes version alone.

NFS is a specific limitation in the documentation. The Linux NFS client does not support the required idmapped mounts, so NFS volumes cannot be mounted in a user-namespace pod. I would identify that incompatibility before proposing a broad template change. The right response depends on the workload's storage requirements and cannot be decided by the API graduation status.

ID allocation is part of node configuration

By default, the kubelet assigns participating pods host IDs above the range used for container IDs. The documentation describes the default valid container UID and GID range as zero through 65535. Files outside the mapped range appear under an overflow identity and cannot simply be modified by running as that overflow user. Images containing unusual ownership therefore need an explicit check.

The kubelet can use a custom subordinate range. That configuration has constraints on alignment, capacity, and overlap. The documented setup uses a system user named kubelet, the getsubids utility, and subordinate UID and GID entries. It does not change which user runs the kubelet process. I would avoid interpreting subordinate-ID configuration as a conversion to running the kubelet without host privileges.

The per-pod ID count is configurable through KubeletConfiguration. The documentation says the count must be a multiple of 65536 and that a changed value applies to containers created after the kubelet starts with that configuration. Running containers keep their existing behavior. Any plan to change allocation sizes should therefore account for the transition between existing and newly created containers.

For a declarative node platform, I would record this alongside the runtime configuration. The review should establish that the allocated ranges avoid host identities and other assignments. It should also explain the workload requirement for departing from the default. More available IDs are not a substitute for understanding an image's ownership model.

Some workloads deliberately share host resources

The feature cannot be combined with hostNetwork, hostIPC, or hostPID set to true. The documentation also prohibits raw block volumeDevices in containers, including initialization and ephemeral containers. These constraints make a workload inventory necessary before cluster-wide policy changes. A host-integrated agent and an ordinary application may need different configurations.

Pod Security admission also accounts for the changed identity model. The documentation describes controlled relaxations of checks on user settings for Linux pods using user namespaces. I would examine those details before concluding that a policy check had stopped working. Root inside an isolated user namespace has a different host-privilege meaning, and the admission behavior reflects that distinction.

For adoption, I would first verify node and volume prerequisites, then test the workload's actual file access and startup under hostUsers: false. The kubelet exports counters for attempted user-namespaced pod creation and creation errors. I would include those observations with the application's own checks when evaluating the change. A successful API submission is only the start of establishing that the intended workload runs with the new identity mapping.