Ingress NGINX Retirement: Migrate to Gateway API

The Kubernetes project stopped maintaining Ingress NGINX in March 2026, so every cluster still running it has an internet-facing controller, usually with read access to every Secret in the cluster, that will receive no further security fixes. Existing deployments keep working, which is exactly the danger: as the Kubernetes Steering and Security Response Committees put it, unless you check, you may not know you are affected until you are compromised. This guide covers the official timeline, how to find Ingress NGINX across clusters, why its annotations are the core risk, how to contain it while you migrate, and how to move to Gateway API or another supported Ingress controller without outages. It is for platform engineers, Kubernetes administrators and cloud security teams. Cluster hardening in general is covered in the Kubernetes Security Guide.

This is an independent guide from NHI Mgmt Group, based on the Kubernetes project's public documentation as of November 2026. It is not sponsored or reviewed by the Kubernetes project. Product features change, so confirm settings against the Kubernetes project's current documentation.

Key takeaways

Maintenance has ended. SIG Network and the Security Response Committee announced that best-effort maintenance would continue until March 2026, after which there are no releases, bug fixes or security updates. Helm charts and images remain downloadable, which does not make them safe.
One command finds most installs. kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx, run with cluster administrator rights, is the check the Kubernetes project gives; also look for the IngressClass controller value k8s.io/ingress-nginx.
The risk is the configuration surface. Annotations translate into raw NGINX configuration, and the controller can read all Secrets by default, so restrict who can reach the admission webhook and apply the last patched release.
No replacement is drop-in. The Kubernetes project says so directly. Ingress NGINX has surprising behaviours (prefix and case-insensitive regex, implied regex, URL normalisation) that a literal translation will break.
Gateway API is the recommended destination. The Ingress API is frozen; Gateway API moves redirects, header matching and traffic splitting into standard fields, and Ingress2Gateway 1.0 translates over 30 common Ingress NGINX annotations.

What is changing and why

Ingress NGINX (the kubernetes/ingress-nginx project) began as an example implementation of the Ingress API and became one of the most widely deployed controllers, bundled into many hosted platforms. The 29 January 2026 statement from the Steering and Security Response Committees cites internal Datadog research that about half of cloud native environments rely on it. It is not the same product as F5's NGINX Ingress Controller; both use NGINX as the data plane but are otherwise unrelated, and this retirement affects only the community project.

The retirement announcement gives two reasons. First, maintenance: for years the project had one or two people doing development in their own time, and a planned successor, InGate, never matured and is also being retired. Second, design: the announcement says features once considered helpful, such as adding arbitrary NGINX directives through "snippets" annotations, have come to be considered serious security flaws, and calls the accumulated flexibility insurmountable technical debt. The project README now warns not to deploy it if you are not already using it, and that it assumes anyone who can create Ingress objects is a cluster administrator.

The Ingress API itself is not being removed, but the Kubernetes documentation states the Ingress API has been frozen and recommends Gateway instead. Staying on Ingress with a different controller is allowed; it is simply the less future-proof option.

Official timeline and current status

Dates as published by the Kubernetes project, checked 8 November 2026.

Date	Event	Source
24 March 2025	Patches v1.12.1 and v1.11.5 released with security fixes	Kubernetes blog, Security Response Committee
11 November 2025	Retirement announced; best-effort maintenance until March 2026	Kubernetes blog, SIG Network and SRC
29 January 2026	Joint statement from Steering and Security Response Committees urging immediate migration	Kubernetes blog
March 2026	Maintenance halted; no further releases, bug fixes or security updates; repositories to be made read-only	Retirement announcement
20 March 2026	Ingress2Gateway 1.0 released by SIG Network	Kubernetes blog
Now	Existing deployments still run; artifacts remain available; any new vulnerability stays unfixed upstream	Retirement announcement

Some platform vendors and distributions bundle the controller. If yours does, ask the vendor in writing what support, if any, they provide after the upstream retirement, and for how long.

Who and what is affected

Self-managed clusters that installed the ingress-nginx Helm chart or manifests, including dev and test clusters that are reachable from corporate networks.
Managed Kubernetes add-ons where a provider deployed Ingress NGINX for you; check the add-on's own lifecycle notice.
Products that embed it inside their own Helm charts, such as internal platforms, CI systems or vendor appliances running on Kubernetes.
Every application team whose Ingress objects use nginx.ingress.kubernetes.io annotations, because those behaviours must be reproduced or deliberately dropped.
Multi-tenant clusters where developers can create Ingress objects: the project itself says not to use it in multi-tenant production.

Finding affected systems and identities

Run the official check in every cluster: kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx. Labels can be changed, so also search for containers using the ingress-nginx/controller image from registry.k8s.io, and IngressClass objects whose spec.controller is k8s.io/ingress-nginx.
Record the version: anything older than v1.12.1 or v1.11.5 predates the March 2025 security fixes and must be patched or contained immediately.
Inventory Ingress objects and annotations: list every Ingress with ingressClassName nginx (or the legacy class annotation) and extract all nginx.ingress.kubernetes.io/* annotations. Count how many use snippets, rewrite-target, use-regex, auth-url, CORS and backend protocol annotations. This becomes the migration backlog.
Check the risky ConfigMap settings: allow-snippet-annotations (default false; true means users can inject NGINX configuration) and annotations-risk-level (default High; Critical accepts the most dangerous annotations).
Map the controller's identity: review the ClusterRole bound to the controller's service account. The Kubernetes security team notes that by default it can read all Secrets cluster-wide, which is why a configuration injection becomes cluster takeover.
Check the admission webhook exposure: find the ValidatingWebhookConfiguration named ingress-nginx-admission and confirm which networks can reach the controller's webhook port, and limit it to the API server.
Use your platform tools: container image inventory in your CSPM, SBOMs and registry scans catch clusters nobody listed. See the Kubernetes Audit Log Detection Guide for finding who creates and edits Ingress objects.

Finding	Risk	Immediate containment
Version below v1.11.5 or v1.12.1	Missing the March 2025 security fixes	Upgrade to the last patched release, or disable the validating admission webhook as the SRC advised
allow-snippet-annotations true	Any Ingress author can inject NGINX directives	Set to false; move needed snippets into reviewed controller config
annotations-risk-level Critical	Highest-risk annotations accepted	Lower to High or Medium after checking which annotations break
Controller can read all Secrets	Injection exposes every credential in the cluster	Restrict watched namespaces and Secret access where the install supports it
Developers can create Ingress objects freely	Configuration injection by any namespace user	Restrict Ingress create and update via RBAC and admission policy

Migration options

Option	What it involves	Choose when	Trade-offs
Gateway API implementation	Install Gateway API CRDs and a conformant implementation; translate Ingress to Gateway and HTTPRoute (or GRPCRoute)	You can invest engineering time and want the long-term standard	Larger change; behaviour differences per implementation; teams learn new resources
Another Ingress controller	Swap the IngressClass to a supported controller; translate annotations to its equivalents	Many teams depend on Ingress and you need the fastest safe exit	Ingress API is frozen; vendor-specific annotations recreate lock-in
Cloud provider load balancer controller	Use the provider's native Ingress or Gateway integration	Single-cloud clusters already using provider load balancers	Provider-specific features and cost model
Contain and stay (temporary)	Last patched version, snippets off, webhook restricted, RBAC tightened	Only as a dated bridge while migration runs	No upstream fixes for anything new; risk grows every month

The Kubernetes documentation keeps a vendor-neutral list of Ingress controllers and the Gateway API site lists implementations with their conformance reports. Choose on conformance, the features your annotation inventory actually needs, support model and how the implementation scopes its own credentials, not on popularity.

Why Gateway API changes the security model

Role separation: Gateway API splits infrastructure (GatewayClass), listeners and TLS (Gateway, owned by cluster operators) and routing (HTTPRoute, owned by application developers). Application teams no longer edit the configuration that terminates TLS.
Standard fields instead of annotations: redirects including HTTPS redirects, header and request manipulation, traffic splitting, and header, query or method matching are part of HTTPRoute. The Gateway API project discourages annotations on Gateway API resources.
Explicit attachment: routes attach to Gateways through parentRefs, so which teams can expose what is visible in the resources and controllable with RBAC.

Using Ingress2Gateway

Ingress2Gateway 1.0 reads Ingress manifests from files or from a cluster and prints Gateway API resources, translating over 30 common Ingress NGINX annotations (CORS, backend TLS, regex matching, path rewrite and others) and warning about configuration it cannot translate. SIG Network describes it as a migration assistant, not a one-shot replacement: review every warning, and treat untranslatable snippets as a chance to discard configuration you should not have had.

Testing and rollback

Run side by side: deploy the new controller or Gateway with its own IngressClass or GatewayClass and its own load balancer address, while Ingress NGINX keeps serving production.
Test the known traps: the Kubernetes blog lists five Ingress NGINX behaviours that break naive translations: regex matches are prefix-based and case-insensitive; use-regex applies to every path on a host across all Ingresses; rewrite-target implies regex; requests missing a trailing slash are redirected; and URLs are normalised. Replay real traffic paths against both and compare status codes.
Shift traffic gradually: move one hostname at a time with DNS weighting or a front load balancer, starting with low-risk services.
Rollback: keep Ingress NGINX and its DNS records in place until each hostname has run cleanly on the new path for an agreed period; rollback is pointing DNS back. Keep the window short, because the old controller is unpatched.
Decommission completely: delete the controller Deployment or DaemonSet, the ingress-nginx-admission webhook configuration, its ClusterRole and bindings, its service account and the IngressClass, so nothing can be scheduled back onto it.

Risks of doing nothing

Unfixed vulnerabilities on the edge: the controller parses untrusted HTTP from the internet and configuration from inside the cluster. Any new flaw after March 2026 stays open.
Cluster-wide credential exposure: because the controller can read all Secrets by default, a single injection can expose database passwords, cloud keys and service account tokens (ATT&CK T1552.007, Container API). See the Kubernetes Secrets Security Guide.
Silent persistence: nothing breaks on the retirement date, so unowned clusters keep running it indefinitely.
Audit and supply chain findings: unsupported components fail NIST SP 800-53 SA-22 and CIS Control 2.2, and scanners will flag the image.

Where identity fits

The controller is a non-human identity with some of the broadest rights in a typical cluster: a service account bound to a ClusterRole that, by default, reads Secrets everywhere. When you choose a replacement, check what its service account can read, whether it can be limited to the namespaces holding TLS certificates, and whether Gateway API ReferenceGrant or namespace scoping lets you avoid cluster-wide Secret access. Remove the old service account and bindings on decommission. See the Kubernetes RBAC Guide and the Kubernetes NHI Security Guide.

Detection, metrics and framework mapping

Clusters still running Ingress NGINX: count across all environments, trending to zero.
Hostnames migrated: percentage of production hostnames served by the new controller or Gateway.
Snippet use: Ingress objects using snippet annotations, trending to zero before cutover.
Containment: remaining Ingress NGINX installs on the last patched version with snippets disabled.
Change monitoring: alert in Kubernetes audit logs on create or update of Ingress objects carrying nginx.ingress.kubernetes.io annotations, and on reads of Secrets by the controller service account outside its expected namespaces.

Framework	Reference	How it applies
NIST CSF 2.0	ID.AM-08, PR.PS-02	Lifecycle management; replace software commensurate with risk
NIST SP 800-53 Rev. 5	SA-22, CM-8, AC-6, SC-7	Unsupported components, inventory, least privilege for the controller, boundary protection at the edge
CIS Controls v8.1	2.2	Ensure authorised software is currently supported
MITRE ATT&CK	T1190, T1552.007, T1613	Exploitation of the edge controller, credential access through the Kubernetes API, cluster discovery after compromise

Practitioner checklist

Run the official kubectl check and image search in every cluster, including dev and vendor-managed ones.
Patch any install below v1.12.1 or v1.11.5, or disable the validating admission webhook now.
Set allow-snippet-annotations to false and review annotations-risk-level.
Restrict who can create or update Ingress objects and narrow the controller's Secret access.
Export every nginx.ingress.kubernetes.io annotation in use as the migration backlog.
Choose Gateway API or a supported controller using conformance and your annotation needs.
Translate with Ingress2Gateway, resolve every warning and test the five known behaviour traps.
Run side by side, shift hostnames gradually and keep DNS rollback ready for a short window.
Remove the controller, webhook, RBAC, service account and IngressClass when done.

Ingress NGINX Retirement: find it, contain it and migrate safely