Now is the time for Gateway API

For many Kubernetes teams, Ingress-NGINX has been the default answer for years. It was available, well known, and broadly documented. It became part of the mental model of Kubernetes: create an Ingress, add a few annotations, point DNS to the load balancer, and move on. 

That era is over. 

The Kubernetes project announced the retirement of Ingress-NGINX with a clear consequence: after March 2026, there would be no further releases, no bug fixes, and no updates to resolve newly discovered security vulnerabilities. Existing deployments continue to run, and existing artifacts remain available, but that is very different from having a maintained security boundary in front of your applications. [1] 

This distinction matters. Nothing explodes overnight. Traffic still flows. Dashboards may stay green. But the risk profile changes completely. A central component sitting at the edge of your Kubernetes cluster is no longer receiving upstream fixes. 

That is not a warning light you can ignore. 

The retirement would already be enough reason to plan a migration. Recent vulnerabilities make the situation more concrete. 

In 2026, multiple Ingress-NGINX issues were disclosed, including CVE-2026-4342 and CVE-2026-3288. Both involved NGINX configuration injection paths that could lead to arbitrary code execution in the context of the Ingress-NGINX controller and disclosure of Secrets accessible to that controller. [2] 

Then CVE-2026-42945 in NGINX itself. NVD lists it as a vulnerability in NGINX Plus and NGINX Open Source in the ngx_http_rewrite_module, with a CVSS 4.0 score of 9.2, and notes that exploitation can cause a heap buffer overflow and, under certain conditions, code execution. NGINX published fixed versions for its own upstream releases, marking NGINX 1.30.1+ and 1.31.0+ as not vulnerable. [3] [4] 

That is exactly the operational problem: when the upstream web server or a dependency gets patched, a maintained downstream controller must absorb, test, package, and release the fix. But the Kubernetes Ingress-NGINX project has already stated that after retirement there are no more releases and no more security updates.[1][5] 

For a component that terminates external traffic, handles headers, touches TLS, and often has privileged visibility into cluster resources, 'it still runs' is no longer a security strategy. 

The obvious reaction is: 'Let's switch to another Ingress controller.' That may be a valid emergency step in some environments. But it should not be confused with a long-term platform decision. 

The Kubernetes documentation is explicit: the project recommends using Gateway API instead of Ingress, and the Ingress API is frozen. Kubernetes has no current plan to remove Ingress, but the API is no longer being developed and will receive no further feature updates. Therefore, the limitation will stay, no segregations of tasks, no multitenancy, no clean multiprotocol support or traffic management, without “annotation hell”. [6] 

The Gateway API project is equally direct: Gateway API is the successor to the Ingress API. [7] 

This is the strategic point. 

Moving from Ingress-NGINX to another Ingress implementation still requires engineering effort, with the risk of ending in a vendor lock-in again. You have to audit annotations, translate controller-specific behaviour, retest edge cases, rework Helm values, adapt observability, update runbooks, and validate traffic cutover. If you already have to do that work, why invest it in an API that Kubernetes itself says is frozen? 

A pure Ingress-to-Ingress migration can reduce the immediate maintenance risk, but it leaves the bigger problem unsolved. The next modernization project is still waiting. 

Gateway API is the chance to move once. 

Gateway API is often introduced as 'the new Ingress.' That undersells it. 

Ingress was simple, but its simplicity became a trap. As soon as teams needed redirects, rewrites, header handling, timeouts, traffic splitting, external authentication, or advanced policy behavior, they reached for annotations. Those annotations were powerful, but they were also implementation-specific, welcome to the annotation hell. What worked in one controller did not necessarily work in another and a simple query for annotation is also not possible and makes working with it not easy. 

Gateway API changes the model. It separates responsibilities. Platform teams define shared entry points (GatewayClass and Gateway). Application teams define access paths (HTTPRoute). Policies can be attached in a structured way instead of being hidden inside long annotation lists. The Gateway API migration guide calls out this persona model as one of the major differences from Ingress. [7] 

That is not just cleaner YAML. It is a better operating model for real Kubernetes platforms. 

It means platform teams can own the shared security and traffic infrastructure, while application teams keep ownership of their application routes. It means fewer unsafe copy-pasted annotations. It means better separation of duties. And it gives security teams a much better place to attach consistent controls. While the application teams do not interfere with each other. 

Ingress API was never built for multi-tenant, role-oriented infrastructure, as it relies heavily on proprietary, vendor-specific annotations that clutter manifests. 

Airlock Microgateway is built for exactly this transition: Kubernetes-native traffic handling combined with Web Application and API Protection (WAAP) as well as an integrated Identity-Aware Proxy (IAP). 

The migration away from Ingress-NGINX is not only a routing migration. It is also a security migration. 

It should help enforce the security posture of the platform. That includes request filtering, consistent policies, authentication integration, and a supported update path for security-critical components. 

Airlock Microgateway brings those concerns closer to where modern Kubernetes teams already work: GitOps, CI/CD, platform engineering, and security as code. [8] 

The Ingress-NGINX retirement is also pushing the ecosystem forward. 

More Helm charts are adding Gateway API support, documenting Gateway API paths, or opening issues to track the transition. GitLab chart users are also tracking Gateway API support as a desired replacement path for Ingress. [9] 

Not every chart is ready today. That is expected. The question is how we react. We can complain that our favourite chart does not support Gateway API yet and use that as a reason to delay. Or we can treat this as an opportunity to contribute. 

Many open-source Helm charts accept pull requests. 

This is how the Kubernetes community moves forward: not by waiting until every chart is perfect, but by helping the ecosystem adopt the better API. 

A good migration does not start with replacing YAML blindly. It starts with understanding what you actually run. 

First, identify where Ingress-NGINX is used. The Kubernetes retirement blog suggests checking for Ingress-NGINX pods with the label selector app.kubernetes.io/name=ingress-nginx. Then inventory all Ingress objects, TLS secrets, hostnames, path rules, annotations, rewrite rules, timeouts, authentication behaviour, custom snippets, and monitoring expectations. [1]  

Next, decide not only which controller replaces Ingress-NGINX, but which API model your platform should standardize on. For most teams, that should be Gateway API. 

Then introduce Airlock Microgateway as a Gateway API implementation. Start with Microgateway as data plane to validate routing and operational behaviour. Convert selected Ingress resources into Gateway and HTTPRoute resources. Run old and new paths side by side where possible. Test DNS, certificates, headers, redirects, application callbacks, health checks, and observability. 

With Ingress2Gateway most of it can already be automated and minimized the effort. Ingress2gateway helps to translate Ingress to Gateway API resources. [10]

After routing is stable, add the security layers like request filtering or authentication where they matter. That is where Microgateway becomes more than *just* an Ingress replacement. It becomes part of your Kubernetes security architecture. 

Finally, you can remove Ingress-NGINX and let it rest in peace. 

 

Even though the removal of the Ingress API has not been announced, it does not mean that it will not change in future. 

Ingress is frozen. Ingress-NGINX is retired. The security patch train has ended. The ecosystem is moving toward Gateway API. And the cost of migration cannot be avoided forever. 

So the real question is not: 'Which Ingress controller should replace Ingress-NGINX?' The better question is: 'Since we have to touch this part of the platform anyway, why not move to the API Kubernetes recommends?'[6]  

With Airlock Microgateway, the answer is practical. You get a Kubernetes-native Gateway API data plane, a path toward WAAP and identity-aware security. 

Do not just replace the old controller. Use this moment to modernize the edge of your Kubernetes platform. 

Move from Ingress-NGINX to Gateway API. Move from annotation sprawl to structured policies. Move from 'it still runs' to 'it is supported, secure, and ready for the future.' 

Sources: 

 

[1] Kubernetes Blog: Ingress-NGINX Retirement 

[2] Kubernetes Discuss: Security Advisory CVE-2026-4342 

[3] NVD: CVE-2026-42945 

[4] NGINX Security Advisories 

[5] Kubernetes Ingress-NGINX GitHub Repository 

[6] Kubernetes Documentation: Ingress 

[7] Gateway API: Migrating from Ingress 

[8] Airlock Microgateway Documentation: WAAP and Identity-Aware Proxy 

[9] GitLab Helm Chart Issue: Gateway API Support 

[10] Ingress to Gateway