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

- Link: https://thestackobserver.com/kubernetes-1-36-arrives-user-namespaces-go-ga-ingress-nginx-retires-and-cncf-warns-on-llm-security/
- Published: 2026-04-20T09:18:24-04:00
- Author: Stackxx

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](https://kubernetes.io/releases/)._