Kubernetes v1.36 — codename Haru — landed in 2026 with roughly 70 enhancements, but three General Availability features dominate the platform conversation: User Namespaces, Mutating Admission Policies (MAP), and Fine-Grained Kubelet API Authorization. Together they tighten the security posture of clusters that still run with legacy defaults from the 1.2x era. If your production fleet is more than one minor version behind, the upgrade is less about changelog trivia and more about which defaults now break workloads that assumed root-in-container was fine.
User Namespaces: Root in the Container Is Not Root on the Host
User Namespaces map container UIDs to unprivileged ranges on the host. A process running as UID 0 inside the pod sees root privileges within its namespace but operates as a high, non-overlapping UID outside — reducing the blast radius when a container escape succeeds.
User Namespaces graduated to GA in 1.36 after beta cycles on supported runtimes (containerd 2.x, CRI-O with matching flags). Enabling them requires:
- Kubernetes 1.36+ on nodes
- Runtime support with
feature-gatesor runtime config enabling user namespaces - Pod spec fields or pod security standards that opt workloads in
What breaks: Images that assume they can write to host-protected paths, init scripts that chown system directories, and legacy Helm charts hardcoding runAsUser: 0 without capabilities review. Scan your fleet for privileged pods before flipping cluster-wide policies.
What improves: Multi-tenant clusters, batch jobs from untrusted submitters, and any environment where CIS benchmarks flagged root containers as finding SEC-001.
The Kubernetes 1.36 release notes document runtime-specific enablement. Treat node pools as canary-first — one AZ, one workload class, week of metrics.
Mutating Admission Policies Replace Some Webhook Glue
MAP provides a first-class API for mutation logic that previously lived in custom mutating webhooks — label injection, sidecar attachment, resource defaulting — with lower operational overhead when the policy engine supports your use case.
GA status means production adoption is reasonable, but not every webhook should migrate on day one. Complex external integrations (Vault agent injectors, service mesh proxies with dynamic config) may still need webhooks. MAP fits deterministic, in-cluster mutations expressed as policy.
Audit existing mutating webhooks:
| Candidate for MAP | Keep as webhook |
|---|---|
| Default resource requests/limits | External secret sync with cloud API calls |
| Standard labels/annotations from namespace | Mesh bootstrap talking to control plane |
| Pod security context defaults | Custom image rewriting via registry API |
Test mutation ordering — MAP interacts with existing admission chain position. Duplicate mutations (webhook + MAP setting the same field) produce debugging nightmares.
Fine-Grained Kubelet API Authorization
Kubelet APIs historically exposed more surface area than RBAC granularity could limit. Fine-grained authorization splits read-only stats queries from exec/attach/port-forward — letting you grant monitoring scrapers metrics without handing them shell access.
Platform teams running centralized observability agents should rewrite ClusterRoles that bundled nodes/proxy permissions. Split roles:
- Metrics collector — get/list nodes, stats/summary only
- Break-glass debugger — exec/attach with approval workflow and time-bound RoleBinding
This aligns with zero-trust patterns our Kubernetes RBAC guide describes — least privilege by API verb, not by resource alone.
Additional 1.36 Changes Worth a Ticket
Not GA, but likely on your radar if you operate at scale:
- Device plugin API updates for GPU scheduling — pairs with DRA (Dynamic Resource Allocation) work continuing across 1.35–1.36
- In-place pod resource resize improvements — fewer evictions on vertical scaling
- Structured logging migration — component logs moving toward consistent key/value fields for Loki/Datadog parsers
Scan the full enhancement list against your platform roadmap; 70 items means something touches your stack.
Upgrade Playbook
- Read deprecated API removals — 1.36 drops beta APIs your GitOps repo may still reference. Run
plutoorkubentagainst manifests. - Upgrade control plane — managed EKS/AKS/GKE versions lag upstream; confirm cloud provider release notes for 1.36 availability in your regions.
- Upgrade node pools — match kubelet to API server minor; drain sequentially.
- Enable features incrementally — User Namespaces on staging, MAP policies on non-production namespaces, kubelet authz before prod.
- Watch admission latency — new policy layers add milliseconds; alert on webhook/MAP p99.
Defaults Are the Story
Earlier releases made secure options available. 1.36 makes them harder to ignore — GA features, tighter kubelet boundaries, and documentation pushing pod security standards as the baseline. Teams still running privileged DaemonSets because “it always worked” will feel this release more than teams already on restricted PSS.
Upgrade for the CVE patches, but plan the migration work for User Namespaces and admission policy refactors. That is where 1.36 Haru earns its place in the platform calendar — not as a semver bump, but as the release security defaults finally caught up to how multi-tenant Kubernetes is actually used.
