Kubernetes v1.36 Sneak Peek: Security Hardening, Smarter Device Scheduling, and Faster SELinux Volume Mounts

AI generated image for Kubernetes v1.36 Sneak Peek: Security Hardening, Smarter Device Scheduling, and Faster SELinux Volume Mounts

Kubernetes releases have a particular rhythm: half engineering marathon, half group therapy session, and one small part “wait, we were using that feature?” Kubernetes v1.36 looks like it will continue that proud tradition—except this time the big story is not flashy new abstractions, but the kind of platform plumbing that quietly saves your weekend.

This article is based on the upstream Kubernetes blog post “Kubernetes v1.36 Sneak Peek” by Chad Crowell, Kirti Goyal, Sophia Ugochukwu, Swathi Rao, and Utkarsh Umre. The original post is worth reading in full for the authoritative upstream view and links to the relevant enhancement proposals and documentation.

Upstream’s headline is simple: Kubernetes v1.36 is planned for Wednesday, April 22, 2026, and it includes notable deprecations/removals plus a set of enhancements aimed at security, performance, and better device management for modern workloads. citeturn1view0

Below, I’ll translate what’s in the sneak peek into practical operator impact: what to test now, what might break later, and why a couple of these changes matter more than they look at first glance.

What’s the big theme of Kubernetes v1.36?

If Kubernetes v1.34 and v1.35 were about improving the ergonomics and correctness of day-to-day operations, v1.36 feels like a release that doubles down on three long-running trends:

  • Security hardening by removing risky legacy knobs (hello, gitRepo and externalIPs).
  • Reducing “death by a thousand papercuts” startup latency (SELinux labeling improvements going GA).
  • Making Kubernetes less awkward around accelerators (Dynamic Resource Allocation improvements, including new scheduling controls and better sharing of expensive hardware).

That’s a very 2026 Kubernetes story: the platform is mature, ubiquitous, and increasingly used for AI/ML, edge, and multi-tenant environments. So the upstream project is spending effort where the pain is most expensive: security exposure, performance cliffs, and hardware utilization.

Kubernetes v1.36 release timing (and why “end of April” matters)

The upstream sneak peek calls out that Kubernetes v1.36 is coming “at the end of April 2026” and lists the planned release date as April 22, 2026. citeturn1view0turn0search7

Operationally, this matters because managed Kubernetes providers typically roll a new minor version through preview channels first, then into “regular” channels with some lag. If you run EKS/GKE/AKS or an enterprise distribution, v1.36 features will show up on vendor timelines, not on upstream’s. But deprecation warnings (and CI signal, and tooling updates) tend to show up quickly once the upstream release is out.

The Kubernetes API removal/deprecation process (a quick refresher, because it’s always exam season)

The upstream post includes a reminder that Kubernetes follows a documented API deprecation policy. The short version: stable APIs can only be deprecated when there is a newer stable replacement, and deprecated functionality must continue to work for a minimum period before removal. citeturn1view0turn4search0

If you’ve ever upgraded a cluster and been greeted by an error like “no matches for kind … in version …”, you already know why this matters. Deprecation warnings are basically Kubernetes’ way of sending you a calendar invite that says: “Hi, future you will be sad. Please accept.”

Deprecations and removals you should not ignore

1) Service .spec.externalIPs is being deprecated (removal planned for v1.43)

Kubernetes v1.36 deprecates Service.spec.externalIPs. Starting in v1.36, you should expect deprecation warnings when you use it, and upstream says full removal is planned for v1.43. citeturn1view0

Why now? Because externalIPs has been considered a security hazard for years. The sneak peek explicitly references CVE-2020-8554, a man-in-the-middle style risk tied to how Services and external IP routing could be abused in certain configurations. citeturn1view0turn4search8

It’s worth being precise here: the existence of externalIPs doesn’t automatically mean “your cluster is compromised,” but it’s a footgun in multi-tenant or loosely governed clusters because it can create surprising traffic interception paths if users can create/modify Services. That’s why policy-based controls and admission controls have historically been recommended mitigations. citeturn4search9turn4search8

What to do about it:

  • Inventory usage: search manifests and Helm charts for externalIPs.
  • Decide the real intent: are you using it as a “quick and dirty” load balancer, as static routing in bare metal, or as part of some legacy network integration?
  • Migrate to more standard exposure patterns: LoadBalancer Services (with a real LB integration), Ingress/Gateway API, or a bare-metal LB like MetalLB—depending on your environment.
  • Harden multi-tenancy: If you must keep it during the deprecation window, ensure RBAC and admission policies restrict who can set externalIPs.

Also: because removal is planned for v1.43, you don’t have to fix this on April 22, 2026—but the warning starts in v1.36, which means CI/CD and policy checks should begin enforcing the new direction now, while it’s still “just warnings.” citeturn1view0

2) The gitRepo volume driver is permanently disabled in v1.36

The gitRepo volume type has been deprecated since Kubernetes v1.11, and in v1.36 it becomes permanently disabled and “cannot be turned back on,” according to the upstream sneak peek. citeturn1view0

Upstream frames this as a security-driven move: leaving gitRepo available created risk, including a scenario where an attacker could potentially run code as root on the node. citeturn1view0turn4search3

Security researchers have discussed vulnerabilities involving gitRepo volumes (for example, CVE reports and advisories describing command execution risks through abusive repository content and clone behavior). citeturn4search3turn4search1

What to do about it:

  • Find any remaining gitRepo usage in YAML, Helm templates, or old manifests checked into repos “nobody uses anymore.” (Those are the ones that page you at 2 a.m.)
  • Replace it with an init container that clones content into an emptyDir (or a persistent volume, if you need it) using a known-good image and explicit pinning.
  • Consider a purpose-built git-sync sidecar/init approach for periodic updates instead of cloning at pod startup.
  • Re-evaluate the pattern entirely: if you were using gitRepo to “configure apps from Git,” you may be better served by baking config into images, using ConfigMaps/Secrets, or adopting GitOps tooling where Git is the source of truth for manifests, not runtime file fetches.

The important operational difference versus externalIPs: this is not a “warn now, remove later” change. v1.36 flips the switch to “disabled, forever.” If you have workloads still relying on it, they will fail immediately after upgrading. citeturn1view0

Featured enhancements in v1.36 that deserve your attention

Faster SELinux labeling for volumes goes GA (and yes, this can be a big deal)

One of the most operator-friendly v1.36 changes is the SELinux volume mounting improvement reaching General Availability (GA). Upstream describes it as replacing recursive relabeling with applying the correct label at mount time (for example via mount options), which reduces Pod startup delays on SELinux-enforcing systems. citeturn1view0turn3search6

Why you should care even if you’re not a SELinux enthusiast (and many people are only SELinux enthusiasts after they’ve suffered): recursive relabeling can be painfully slow on volumes with lots of files. If you run stateful workloads, image unpacking, large dependency trees, or CI workloads that generate piles of small files, this can become a startup tax that scales with “how many files your app thinks is reasonable.” (Which is always “too many.”)

The upstream sneak peek notes that this feature now defaults more broadly, with the ability to opt out via securityContext.seLinuxChangePolicy: Recursive to help handle conflicts, and an opt-in path via spec.SELinuxMount for Pods or CSI drivers depending on compatibility. citeturn1view0

Practical implications:

  • Faster pod startup on SELinux-enabled nodes, especially with large volumes or many files.
  • More predictable performance instead of occasional “why did this Deployment roll take 20 minutes?” mysteries.
  • Potential edge cases when multiple Pods with different SELinux labels share the same volume, which is why Kubernetes has offered gates and policies around this behavior in prior releases. citeturn3search0turn3search6

Testing advice: If you run on RHEL/Fedora/CoreOS-derived nodes (or any SELinux-enforcing environment), test rollouts of stateful apps and high-churn pods in staging with v1.36 as soon as your distro or managed provider offers it. This is the kind of change that is beneficial when it works, but can be confusing if your storage stack or workload assumptions are unusual.

External signing of ServiceAccount tokens is expected to be GA

Kubernetes is also pushing deeper into external key management and stronger separation of duties. The sneak peek says that in v1.36, the API server can delegate ServiceAccount token signing to external systems such as cloud KMS or HSM-backed services, and that the feature is expected to graduate to GA. citeturn1view0turn2view1

This is part of a broader theme: clusters increasingly live in environments where central security teams want to manage signing keys in dedicated systems, and platform teams want Kubernetes to integrate cleanly with that reality rather than insisting that the control plane must own every cryptographic secret.

In the enhancements tracking issue for KEP-740, the stable target is v1.36 and the issue describes “External signer integration for service account tokens.” citeturn2view1

Who benefits most:

  • Regulated environments that need centralized key custody and audit trails.
  • Large enterprises running many clusters and wanting consistent key rotation practices.
  • Security-conscious platform teams that prefer HSM-backed keys or managed KMS over local private keys on control plane nodes.

What to watch for: external signing introduces dependencies (availability, latency, failure modes) between the API server and the signer. So while it can improve key management, it also needs reliability engineering: clear timeouts, retries, and operational procedures for signer outages. This is not unique to Kubernetes—it’s the same tradeoff you make whenever you centralize security primitives.

DRA device taints and tolerations graduate to Beta

Dynamic Resource Allocation (DRA) is Kubernetes’ long-term plan for handling specialized hardware (GPUs, FPGAs, smart NICs, and all the other expensive toys). The sneak peek says that DRA device taints and tolerations graduate to Beta in v1.36, and it highlights that this is meant to let DRA drivers (or administrators) keep certain devices from being scheduled unless explicitly tolerated—similar in spirit to node taints/tolerations. citeturn1view0turn3search4

In practical terms, this gives you a more Kubernetes-native way to express policies like:

  • “Only these namespaces may use the premium GPUs.”
  • “Avoid scheduling on devices marked as flaky, quarantined, or in maintenance.”
  • “This accelerator is reserved for workloads that explicitly opt in and declare the right tolerations.”

Upstream notes two approaches: drivers can taint individual devices, or admins can define rules (like a DeviceTaintRule) to taint devices matching criteria such as driver type. citeturn1view0

Why it matters: In heterogeneous clusters, “GPU scheduling” is rarely just “give me a GPU.” It’s also: give me a specific kind of GPU, in a specific health state, with a specific policy attached. DRA is the upstream effort to make these constraints first-class rather than duct-taped via annotations, custom schedulers, or vendor plugins.

DRA support for partitionable devices (better sharing of pricey accelerators)

The sneak peek also calls out that Kubernetes v1.36 expands DRA with support for partitionable devices, allowing one physical accelerator to be split into logical units that can be shared across workloads. citeturn1view0

This concept is especially relevant for GPUs and similar accelerators, where dedicating a whole device to one workload can be wasteful. Partitioning and sharing can drive utilization up and cost per workload down—assuming the hardware and drivers support it.

Upstream documentation on DRA describes partitionable devices and notes that DRA is intended to provide a structured mechanism for allocation and scheduling beyond the “whole device” model. citeturn3search4turn3search3

There is also a tracked enhancements issue for DRA Partitionable Devices (KEP-4815), which is part of the upstream roadmap for this area. citeturn3search7

A real-world comparison: In many environments today, “GPU sharing” is accomplished through vendor tooling, device plugin conventions, or hardware-specific partitioning features (for example, slicing). DRA’s ambition is to make the allocation model and scheduling constraints more standardized so the Kubernetes scheduler and ecosystem tooling can reason about it consistently.

How these changes fit into the broader Kubernetes and cloud-native ecosystem

Security posture is moving from “optional best practice” to “default expectation”

The deprecation of externalIPs and the permanent disablement of gitRepo are emblematic of Kubernetes’ slow-but-steady shift: remove high-risk legacy behaviors even if they were convenient.

It’s also a reminder that Kubernetes security vulnerabilities are not always “buffer overflow in the control plane.” Sometimes they’re the ugly emergent behavior of networking primitives, multi-tenant permissions, or legacy features that never should have been easy in the first place. The mitigation story for CVE-2020-8554, for example, has long included admission control and policy enforcement to constrain dangerous Service configurations. citeturn4search8turn4search9

The platform is essentially acknowledging: “Yes, you can keep doing unsafe things, but we will stop making them the easy default.” Which is the most Kubernetes way to say “no” without actually saying “no.”

Hardware management is now mainstream Kubernetes, not a niche HPC concern

DRA’s continued development—and the focus on partitioning and device-level policy controls—signals that accelerators are no longer special snowflakes bolted onto the cluster. They’re core infrastructure for AI inference, training, media processing, and edge analytics.

Google Cloud’s own guidance on deploying DRA workloads in GKE underscores that the intended audience includes AI/ML and data-heavy workloads. citeturn3search10

Meanwhile, downstream platforms like OpenShift highlight DRA as a key capability for smarter GPU scheduling, and point to upstream evolution. citeturn3search5

Operator checklist: what to do before you upgrade to v1.36

1) Audit manifests for gitRepo volumes (and fix them now)

This is the one that can produce immediate post-upgrade breakage.

  • Search for gitRepo in Git repositories, Helm charts, and generated manifests.
  • Replace with init container + emptyDir or other supported patterns.
  • Document why the new approach is safer (your security team will like you, briefly).

2) Identify and plan migration away from Service.spec.externalIPs

You likely have time, but you should start now because externalIPs tends to show up in older “works on bare metal” recipes, on-prem integrations, and bespoke routing hacks.

  • Inventory: where is it used, by whom, and for what.
  • Pick a replacement exposure model that fits your environment.
  • Add policy controls to stop new usages from being introduced.

3) If you run SELinux-enforcing nodes, test startup behavior on stateful workloads

Because this change is about performance and behavior, you want to validate the “happy path” and the weird path. Specifically:

  • Stateful sets with large volumes
  • Pods that share volumes across different security contexts
  • CSI drivers with specific SELinux constraints

4) If you care about centralized key management, start piloting external token signing

If your org already uses cloud KMS or HSM-backed signing services, v1.36 is a strong signal that upstream supports your model. KEP-740’s tracking issue describes the move to stable in v1.36. citeturn2view1

But treat it like any external dependency: design for failures, observe it, and make the blast radius explicit.

5) For AI/accelerator clusters, revisit device allocation strategy

DRA features like device taints/tolerations and partitionable devices are about reducing waste and increasing control. That is a polite way of saying: GPUs are expensive and everyone wants them yesterday.

If you’ve been using bespoke scheduling rules, node labeling hacks, or vendor-specific mechanisms, this is a good time to track how upstream DRA is evolving and whether your environment can benefit from moving toward standardized APIs. citeturn3search4turn1view0

What could still change before the final v1.36 release?

The upstream sneak peek explicitly notes that it reflects the “current state of v1.36 development” and may change before release. citeturn1view0

That’s not a disclaimer; it’s the Kubernetes way of reminding you that release engineering is an ongoing process. Features can slip, change maturity level, or land with caveats depending on testing and implementation status.

So: treat this as an action plan for testing and migration, not a contractual SLA that every listed item will land exactly as described.

Conclusion: v1.36 is a “boring” release in the best way

Kubernetes v1.36 doesn’t look like a release that will inspire a thousand conference talks titled “Everything Changes.” Instead, it looks like the kind of release that helps platform teams sleep more, burn less money on idle accelerators, and remove some long-standing security liabilities from the default toolbox.

If you only do three things: (1) purge gitRepo, (2) plan your externalIPs exit, and (3) test SELinux volume behavior if it applies to you. Everything else is upside.

Sources

Bas Dorland, Technology Journalist & Founder of dorland.org