Ingress‑NGINX EOL Urgency

A Kubernetes ingress controller is the traffic cop that sits at the edge of a cluster and decides which app gets each incoming request. Ingress NGINX became the default traffic cop in a huge share of cloud-native setups, and the Kubernetes project says it reached retirement in March 2026 with no more bug fixes or security patches after that date. (kubernetes.dev) That does not mean the Kubernetes Ingress API itself disappeared. The Kubernetes project says the old Ingress API still exists, but it is feature-frozen, while new networking work is moving to the Gateway application programming interface, which it calls the modern replacement. (kubernetes.dev, gateway-api.sigs.k8s.io) The urgency comes from how much power an ingress controller has. Datadog’s Security Labs called Ingress NGINX “critical infrastructure” and said a flaw there can become a path to full cluster takeover because the controller sits between the public internet and internal services. (securitylabs.datadoghq.com) Teams got a preview of that risk in March 2025, when the “IngressNightmare” bug CVE-2025-1974 was disclosed with a CVSS severity score of 9.8. Datadog said that flaw allowed unauthenticated remote code execution and could lead to complete Kubernetes cluster takeover. (securitylabs.datadoghq.com, securitylabs.datadoghq.com) Then came CVE-2026-3288 in March 2026. The Kubernetes security advisory says the bug let attackers abuse the `rewrite-target` setting in an Ingress resource to inject NGINX configuration, and the fixed releases were 1.13.8, 1.14.4, and 1.15.0. (discuss.kubernetes.io, nvd.nist.gov) This is why end-of-life changes the math. Before March 2026, a team could at least wait for the next patch; after March 2026, the Kubernetes project says there will be no further releases of any kind for Ingress NGINX, so the next serious flaw becomes your problem alone. (kubernetes.io, kubernetes.dev) The replacement the ecosystem keeps pointing to is the Gateway application programming interface. The official Gateway API migration guide says it is the successor to Ingress and splits traffic policy into clearer pieces, so platform teams can own infrastructure while app teams own routes. (gateway-api.sigs.k8s.io) That split is not just cleaner paperwork. The Kubernetes project says Gateway API has stronger support for Kubernetes-native role-based access control, which means fewer people need permission to touch the most dangerous edge settings in the first place. (kubernetes.io, gateway-api.sigs.k8s.io) Datadog’s migration guide frames the problem as an accidental strategic dependency. A single ingress controller often ends up carrying routing, security policy, certificates, and public entry for dozens or hundreds of services, so swapping it out late becomes like replacing the front door, the lock, and the mailroom at the same time. (datadoghq.com) The migration path now has tooling behind it. Kubernetes announced Ingress2Gateway 1.0 on March 20, 2026 as a project to help convert existing Ingress resources to Gateway API, and cloud vendors like Google now publish step-by-step guides for moving production traffic over gradually instead of in one cutover. (kubernetes.io, docs.cloud.google.com) So the story is not that clusters running Ingress NGINX stopped working on April 1. The story is that one of Kubernetes’ most widely deployed edge components is now retired, recent remote-code-execution bugs showed exactly how exposed that edge can be, and the official advice from Kubernetes and Datadog is to move before the next flaw arrives without a patch. (kubernetes.io, securitylabs.datadoghq.com, datadoghq.com)