The Kubernetes world is facing a massive shift. For years, the NGINX Ingress Controller was the de-facto standard for traffic inside clusters. But the signs are clear: the NGINX project is losing momentum, the original architecture is showing its age, and Kubernetes Ingress itself is officially “frozen”.
You may have heard the warnings about the “Ingress Nightmare” security vulnerabilities (such as CVE-2025-1974). It is time to face reality: legacy Ingress is a security risk.
In this article, we show why switching to the Kubernetes Gateway API with the Airlock Microgateway is not just a necessary evil, but a massive upgrade for both security and architecture.
The “Ingress Nightmare” and the end of an era
Why act now? Two reasons:
- Ingress is frozen: The Kubernetes Ingress API (networking.k8s.io/v1) is no longer being developed. It is functionally limited and leads to “annotation hell” – configurations that are hard to maintain.
- NGINX architectural weaknesses: NGINX is a fantastic web server but was never “cloud native”.
- Ingress-NGINX will be discontinued on 26 March 2026.
This is where Envoy comes in. Unlike NGINX, Envoy was built for the cloud: dynamic, no config reloads, and highly observable. Airlock Microgateway is fully based on Envoy – inheriting its cloud-native architecture.
Then there is the WAF topic (“Secure by Design”):
- ModSecurity is practically in an EOL transition; the NGINX-ModSecurity-WAF has been discontinued.
- OWASP Coraza is interesting as a modern engine but is more of a toolkit: a young ecosystem, and you must solve integration, operations, and tooling yourself.
For enterprise- and security-critical infrastructures, this stack is hard to predict – especially under compliance pressure.
Airlock Microgateway & Gateway API: The new standard
The Ingress API remains minimal and stable but is “feature-frozen”. For anything beyond simple host/path routing, the community now relies on Gateway API, with the following advantages:
- Role-based: The platform team manages GatewayClass/Gateway, app teams manage HTTPRoutes. Multiple teams can use their own HTTPRoute objects with the same hostnames without rollout side effects.
- Powerful features: Header matching, traffic splitting, multiple backends, TLS policies, external authentication.
- Portable & future-proof: A joint standard instead of vendor annotations. No lock-in to specific providers.
In short: Ingress is the past; Gateway API is the future. Anyone migrating anyway (e.g., away from Ingress-NGINX) should not switch to yet another pure Ingress controller.
Gateway API is the official successor to Ingress. It cleanly separates routing and security. Airlock Microgateway uses this design perfectly through the so-called Policy Attachment Model.
This means: Your routes remain standard Kubernetes YAML, while security is “attached” via Airlock CRDs (e.g., AccessControlPolicy & ContentSecurityPolicy).
1. WAAP DNA: ContentSecurityPolicy
While many Ingress controllers are only now trying to retrofit security features, Airlock has been doing nothing else for over 20 years.
Through the ContentSecurityPolicy, you bring proven WAAP features (Web Application and API Protection) to your service.
The approach is different – Immediately armed – Secure by Design:
Instead of (as often with NGINX) allowing everything and explicitly blocking bad traffic, we reverse the model. We strictly define what is allowed (e.g., schema validation & allowed paths via OpenAPI specs). Everything else is discarded. That is Security by Design.
Even without explicit configuration, every application is automatically protected (Immediately armed). Configuration is only needed to override defaults. This ensures that security is never forgotten, and an application can never be exposed unprotected.
2. Strong authentication & IAM integration
Filtering is good – knowing who is acting is better.
That is why Airlock Microgateway brings Identity & Access Management directly into the gateway – a clear differentiator from classic Ingress setups.
Key features:
- Token Introspection: The Microgateway checks access tokens with the issuing Authorization Server (valid, revoked, claims/scopes).
- Token Exchange: External tokens (e.g., from Entra ID or partner IdPs) are translated into internal tokens that exactly match your APIs. Backends see only one consistent internal token format.
- Path-based authentication: With policies you can define, for example:
- /public/** → no auth, WAAP only
- /api/** → access token with specific scopes
- /admin/** → additional MFA requirements
Together with Airlock IAM as a cIAM solution (SSO, MFA, adaptive auth, self-service), the result is an end-to-end platform:
- Microgateway enforces policies and protects services,
- IAM manages identities, logins and risk,
- both are technically aligned.
Instead of Ingress-NGINX + ModSecurity/Coraza + IdP + custom glue, you get WAAP + IAM from one hand – ready to protect!
Migration made easy
Take a look at our running example.
Conclusion: Time to set the course
Sticking with NGINX and Ingress V1 is managing technical debt. With Airlock Microgateway, you shift the paradigm:
- From “legacy web server” to “cloud native”
- From “annotation chaos” to “structured policies (AccessControl & ContentSecurity)”
- From “basic auth” to “advanced IAM integration”
Do not wait until it is too late! Start your migration now!