← Blog
#Kubernetes#Security#Containers#DevOps#Cloud Infrastructure

Kubernetes v1.36: User Namespaces GA and What It Means for Container Security

webhani·

Kubernetes v1.36, codenamed "Haru," was released in May 2026. According to InfoQ, among the 18 features graduating to Stable are User Namespaces and Mutating Admission Policies — two security-focused additions that have been in progress across several releases.

This post focuses on what User Namespaces actually does, why it's valuable, and the practical steps to enable it.

The Problem User Namespaces Solves

Many container images run as root (UID 0) by default. The runAsNonRoot: true security context setting exists precisely to prevent this, but adoption has been slow because legacy images often require root permissions for legitimate reasons — binding to privileged ports, writing to certain paths, running package install scripts, and so on.

The risk: if a container escape vulnerability is exploited, a process running as root inside the container maps to root on the host — full system compromise.

User Namespaces eliminates this mapping. With User Namespaces enabled, UID 0 inside the container maps to an unprivileged UID (≥65536) on the host. The container process still thinks it's root, but the host OS treats it as an ordinary unprivileged user. You get the isolation benefit without requiring image modifications.

Enabling User Namespaces

The feature is enabled per-Pod with hostUsers: false:

apiVersion: v1
kind: Pod
metadata:
  name: secure-app
spec:
  hostUsers: false  # enables User Namespaces
  containers:
    - name: app
      image: myapp:latest
      securityContext:
        runAsUser: 0  # root inside the container
        # ...maps to an unprivileged UID on the host

Kernel requirement: Linux 6.3 or later. Check your node kernels before rolling this out:

kubectl get nodes -o custom-columns='NAME:.metadata.name,KERNEL:.status.nodeInfo.kernelVersion'

On EKS, Amazon Linux 2023 and Ubuntu 22.04+ node groups satisfy this requirement. On older AMIs, hostUsers: false is silently ignored — the Pod still runs, just without UID remapping.

Automating with Mutating Admission Policies

Also graduating to GA in v1.36, Mutating Admission Policies let you enforce hostUsers: false across a namespace without maintaining an Admission Webhook server. The policy is expressed in CEL (Common Expression Language) and runs entirely within the cluster:

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingAdmissionPolicy
metadata:
  name: enable-user-namespaces
spec:
  matchConstraints:
    resourceRules:
      - apiGroups: [""]
        apiVersions: ["v1"]
        resources: ["pods"]
        operations: ["CREATE"]
  mutations:
    - patchType: ApplyConfiguration
      applyConfiguration:
        expression: |
          Object{
            spec: Object.spec{
              hostUsers: false
            }
          }
---
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingAdmissionPolicyBinding
metadata:
  name: enable-user-namespaces-binding
spec:
  policyName: enable-user-namespaces
  matchResources:
    namespaceSelector:
      matchLabels:
        user-namespaces: "enabled"

Label a namespace with user-namespaces: "enabled" and all new Pods in it will have hostUsers: false set automatically. No webhook server to deploy or keep available.

Defense-in-Depth Profile

User Namespaces works best alongside other security settings:

spec:
  hostUsers: false
  securityContext:
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: app
      securityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities:
          drop: ["ALL"]
          add: ["NET_BIND_SERVICE"]

The combination — User Namespaces (UID isolation) + seccomp (syscall filtering) + capability dropping — provides meaningful defense-in-depth without requiring extensive image changes.

Migration Considerations

Volume ownership: HostPath volumes and NFS mounts can develop permission issues when UID remapping is active. File ownership that worked under the host UID mapping may break. Test in staging before rolling out to production.

Image compatibility: Most images work without modification. Images that have startup scripts making assumptions about specific UIDs warrant extra testing. It's a small category but worth checking for your workloads.

Gradual rollout: Use namespace selectors in the Mutating Admission Policy binding to roll out incrementally. Start with dev or non-critical namespaces, validate behavior, then expand to production.

Other Notable v1.36 Features

  • Fine-Grained Kubelet API Authorization (GA): Detailed permission control for the kubelet API, useful in multi-tenant clusters
  • 25 Beta features: Including DRA (Dynamic Resource Allocation) improvements for GPU workload scheduling
  • 25 Alpha features: Enhanced sidecar container capabilities and additional network policy controls

Takeaway

User Namespaces GA removes the primary blocker to running legacy root-requiring images with meaningful host-level isolation. You don't need to rebuild images or negotiate with application teams about runAsNonRoot — you get the isolation benefit without the migration cost.

If your organization has compliance requirements (PCI DSS, SOC 2, ISO 27001), evaluate this now. The path is: check node kernel versions, deploy Mutating Admission Policies for automation, validate volume compatibility in staging, then roll out to production namespaces.

← Back to Blog