User namespaces landing as GA in Kubernetes 1.36 on Amazon EKS is the real operational lever in this release — and it should make platform teams fundamentally rethink how they isolate multi-tenant workloads.
AWS published EKS and EKS Distro builds for Kubernetes 1.36 this week, and the changelog is more than a version bump. Upstream 1.36 brings GA user namespaces, the MutatingAdmissionPolicy API, in-place vertical pod resizing improvements, and richer resource health reporting — and AWS' docs and downstream distro releases are following upstream on this minor.
Why User Namespaces matters
User namespaces finally give teams a kernel-level tool for remapping UIDs/GIDs inside containers without full VM isolation. That isn't a silver bullet for full noisy-neighbor protection, but it removes a big chunk of the historical justification for running an expensive VM-per-tenant model or elaborate host-level shims. In practice this means platform engineers can implement stronger filesystem and capability isolation at the container layer while still benefiting from node density. Note that user namespaces also require runtime and image support (containerd/runc builds and images must be compatible) and you should validate interactions with CSI drivers and volume permission semantics.
This is the right call. For years teams built fragile workarounds: puppeteered UID remapping at the image build step, bind-mounted per-tenant volumes with tricksy permissions, or just living with rootful containers. User namespaces lets you stop pretending those hacks are acceptable.
Admission model and operational fallout
MutatingAdmissionPolicy is the declarative API that addresses many use-cases previously implemented with mutating admission webhooks. Expect two immediate headaches: first, older admission-controller tooling (including some community webhooks and custom controllers) needs testing and often code changes to work with the declarative policy model; second, your upgrade sequencing must account for controller compatibility before you flip cluster binaries.
AWS' lifecycle guidance still recommends one-minor-step upgrades (e.g., n -> n+1). Upgrading control planes, managed node groups, and add-ons must be coordinated — kubectl client skew rules remain a hard constraint. EKS provides a short in-place control-plane rollback window for minor upgrades as a safety measure, but it's insurance, not a substitute for staged testing across clusters and add-ons.
What you should change this week
- Audit any admission webhooks and CRD-dependent controllers for MutatingAdmissionPolicy compatibility and test them on a 1.36 EKS cluster.
- Revisit tenancy and image-promotion models with user namespaces in mind: evaluate UID/GID remap strategies and how they interact with CSI drivers and volume permissions.
- Validate managed node groups and third-party add-ons (CNI, CSI, ingress controllers, policy engines) on a staging 1.36 cluster, following the one-minor-step upgrade flow in AWS docs.
- Align your upgrade cadence with EKS' published support timelines — if your fleet spans multiple minors, set a migration plan to avoid extended-support costs and security drift.
This release is less about a single flashy feature and more about economics and tooling pressure: GA user namespaces and the admission-policy API together will push people off brittle, bespoke isolation and webhook architectures. If your platform still treats Kubernetes upgrades as optional operational maintenance, this 1.36 support window is the signal to change that. In 90 days, the teams that tested admission policies and rethought tenancy will be shipping with fewer hacks; the rest will be paying for technical debt in outages, complex workarounds, or extended-support bills.
Sources
- Amazon EKS and EKS Distro now support Kubernetes version 1.36 (What's New entry via ECS/EKS feed)
- Kubernetes versions on standard support in Amazon EKS
- Updates to Amazon EKS Version Lifecycle – AWS News Blog
- Changelog | EKS Anywhere
- Update an existing cluster to a new Kubernetes version – Amazon EKS
- Amazon EKS release and end-of-support schedule