The Stack Observer
Kubernetes

Kubernetes 1.36 Arrives: User Namespaces Go GA, Ingress NGINX Retires, and CNCF Warns on LLM Security

•Stackxx•Kubernetes

Kubernetes 1.36 officially drops on April 22, 2026, bringing with it a massive slate of 80 tracked enhancements: 18 features graduating to stable (GA), 18 moving to beta, and 26 fresh alpha experiments. This release marks a significant inflection point for the platform—not just for what it adds, but for what it removes and the broader security conversations it’s sparking around AI workloads.

Stable (GA) Features: Security and Flexibility Take Center Stage

1. User Namespaces in Pods

Four years after entering alpha in Kubernetes 1.25, user namespaces are finally production-ready. This feature gives each pod its own isolated user ID namespace, meaning a process running as root (UID 0) inside a container is actually mapped to an unprivileged user on the host. Even if a container escape occurs, the attacker gains almost no access to the underlying node.

Previously, achieving true rootless containers required third-party solutions like gVisor or Kata Containers. Now it’s native: simply set hostUsers: false in your pod spec.

spec:
  hostUsers: false
  containers:
  - name: app
    image: my-app

This is a game-changer for multi-tenant environments and security-sensitive workloads.

2. Mutating Admission Policies

Validating Admission Policies changed the game for in-cluster validation using CEL expressions instead of external webhooks. Now mutating admission gets the same treatment. Rather than maintaining TLS-secured webhook servers and worrying about certificate rotation or cascading failures, you can define mutation logic as native Kubernetes objects.

Before 1.36, a crashing mutating webhook could block pod creation cluster-wide. Now mutations are version-controlled, GitOps-friendly, and eliminate the external dependency entirely.

3. OCI VolumeSource

Getting non-code artifacts into containers has historically been awkward—expanding base images, writing init containers, or fighting ConfigMap size limits. OCI VolumeSource lets you mount any OCI image as a volume, treating model weights, datasets, and configuration files as independently versioned artifacts in your registry.

volumes:
- name: model-weights
  image:
    reference: registry.example.com/models/gpt-mini:v2
    pullPolicy: IfNotPresent

4. External Signing of ServiceAccount Tokens

For organizations with strict key custody requirements, Kubernetes 1.36 enables the kube-apiserver to delegate token signing to external systems—cloud KMS, HSMs, or centralized signing services. Short-lived ServiceAccount tokens can now align with existing audit and rotation policies, satisfying compliance frameworks like PCI-DSS, FedRAMP, and SOC 2.

5. Accelerated SELinux Label Changes

Pod startup delays on SELinux-enforcing systems (common in RHEL/Rocky Linux environments) are about to get much shorter. Instead of recursively relabeling every file on large volumes—a process that could take minutes—Kubernetes now uses SELinux mount options to apply labels at mount time.

This reaches GA after being in beta since 1.27 (April 2023). If your team has battled slow pod startups on SELinux nodes, this upgrade alone may justify the migration.

Key Removals: The End of an Era

Ingress NGINX Retired

As of March 24, 2026, the Ingress NGINX project is officially retired. SIG Network and the Security Response Committee made the decision to prioritize ecosystem safety. There will be no further releases, bug fixes, or security patches.

Existing deployments continue to function, but organizations should evaluate alternative ingress controllers that align with current security and maintenance best practices.

gitRepo Volume Permanently Disabled

Deprecated since Kubernetes 1.11, the gitRepo volume plugin is now permanently disabled starting with 1.36. This protects clusters from a critical security issue where gitRepo could allow arbitrary code execution as root on nodes.

Workloads depending on gitRepo must migrate to init containers or external git-sync tools.

externalIPs Deprecation

The externalIPs field in Service specs is now deprecated, with removal targeted for 1.43. This field has been a known security vulnerability for years, enabling man-in-the-middle attacks (CVE-2020-8554). Organizations should migrate to LoadBalancer services, NodePort, or Gateway API for external traffic handling.

Beta Highlights: Scale to Zero and GPU Partitioning

HPA Scale to Zero

After seven years in alpha (since 1.16), HPA Scale to Zero is finally enabled by default. The Horizontal Pod Autoscaler can now scale deployments to zero replicas when idle—ideal for staging environments and batch workloads. Note that you’ll still need an external metric source like KEDA to trigger scale-up from zero.

DRA Support for Partitionable Devices

Modern GPUs like the NVIDIA A100 support dynamic partitioning via MIG. Previously, partitions had to be configured statically. Now DRA drivers can advertise partitionable devices, allowing Kubernetes to request specific partition sizes at scheduling time rather than pre-slicing hardware upfront. This makes GPU utilization dramatically more flexible.

CNCF Warning: Kubernetes Alone Won’t Secure Your LLMs

Beyond the 1.36 release, the Cloud Native Computing Foundation issued a stark warning this month: Kubernetes alone is not enough to secure LLM workloads.

In a detailed threat model analysis, the CNCF highlights that while Kubernetes excels at orchestration and workload isolation, it fundamentally does not understand AI system behavior. Kubernetes can ensure pods are running and resources are stable, but it has zero visibility into whether prompts are malicious, whether sensitive data is being exposed, or whether a model is interacting with internal systems unsafely.

The core issue: LLMs operate on untrusted input and can dynamically decide actions. By placing an LLM in front of internal tools, APIs, or credentials, organizations introduce a new abstraction layer that can be influenced through prompt input. Traditional Kubernetes controls—RBAC, network policies, container isolation—remain necessary but insufficient.

The CNCF recommends organizations adopt AI-specific controls including:

  • Prompt validation and output filtering
  • Tool access restrictions
  • Policy enforcement at the application layer
  • Frameworks like the OWASP Top 10 for LLMs
  • Human-in-the-loop controls for sensitive operations

The message is clear: operational health does not equal security. A system can be fully compliant with Kubernetes best practices while exposing significant risks through its AI layer.

Upgrade Considerations

Before upgrading to 1.36, audit your clusters for:

  • Ingress NGINX usage — Plan migration to alternative controllers
  • gitRepo volumes — Migrate to init containers or git-sync sidecars
  • externalIPs in Service specs — Transition to Gateway API or LoadBalancer
  • SELinux configurations — Review seLinuxChangePolicy settings for volume compatibility

Bottom Line

Kubernetes 1.36 represents more than a feature release—it’s a statement about the platform’s evolution. Rootless containers are now native. Webhook-free mutations are possible. OCI artifacts are first-class citizens. And the ecosystem is shedding legacy baggage (Ingress NGINX, gitRepo) that no longer meets modern security standards.

At the same time, the CNCF’s LLM security warning signals where the conversation is heading. Kubernetes remains the foundation for cloud-native infrastructure, but securing AI workloads requires thinking beyond the orchestrator to the application layer. The platform is ready for what’s next—the question is whether our security models are.

Kubernetes 1.36 releases April 22, 2026. Full release notes and upgrade guidance are available at kubernetes.io/releases.

Next signal