ingress-nginx patching has stalled, and the Envoy Gateway migration is more than YAML translation

A controller that keeps working

ingress-nginx has not received a security patch since March 2026, according to a post on dev.to. The controller still routes traffic exactly as it always did, and the author's point is that this continuity is precisely why the risk goes unnoticed: nothing breaks, so nothing gets scheduled.

The post frames the exit as the one Kubernetes itself recommends. It cites the Kubernetes blog announcement of Ingress NGINX's retirement, dated 11 November 2025, and points to Gateway API as the successor, with Envoy Gateway as one of its implementations.

The migration is not a translation exercise

The temptation, the author writes, is to treat the move as syntax conversion: take each ingress-nginx annotation and rewrite it in the new format. The post argues that two structural changes make that approach dangerous.

The first is ownership. In nginx, each application carried its own IP access rule in an annotation, maintained by the application's team. In Envoy Gateway, that rule is promoted to a SecurityPolicy attached to a Gateway that is shared across routes. The rule changes hands from the application team to the platform team, and the blast radius grows accordingly: a mistake that used to affect one application now affects every route behind that Gateway.

The second is the layer at which the rule operates. An IP allowlist is a layer-3 decision being made at layer 7, which means the proxy acts on whatever IP it believes belongs to the client. Two failure modes follow, both named in the post. If SNAT occurs anywhere on the path, every caller can collapse into the node's IP. If X-Forwarded-For is accepted without validation, any client can simply declare an address of its choosing.

Four traps the documentation confirms

The author lists four pitfalls that a pure annotation-to-YAML conversion would have gotten wrong, each backed by official documentation:

• SNAT rewriting client addresses before requests reach the proxy.
• Precedence by replacement: Envoy Gateway's SecurityPolicy documentation covers precedence and a mergeType setting, and the author warns that policies can displace rather than combine with each other.
• A wide CIDR copied across from the old rules, opening access further than the original rule intended.
• The API gateway ending up as the only client the backend services ever see.

For teams doing this work, the post points to specific references: Envoy Gateway's guidance on restricting access by IP, its Client Traffic Policy covering X-Forwarded-For and Proxy Protocol, and its SecurityPolicy material on precedence and mergeType, alongside Kubernetes documentation on preserving the client source IP and Microsoft's documentation on the Standard Load Balancer in AKS.

Why it matters

An internet-facing ingress controller without security patches is standing exposure, and the longer the migration is deferred, the more tempting the quick fix becomes. The dev.to post's practical warning is that the quick fix, rewriting annotations one by one, is exactly where access rules silently disappear or silently widen.

The changes the author describes are the ones review processes tend to miss, because none of them looks like a bug: a rule that moves from an app's manifest to a platform-owned policy, a decision that shifts from layer 3 to layer 7, an allowlist whose meaning depends on how client addresses arrive at the proxy. Teams moving off ingress-nginx should plan for verification rather than conversion: confirm how client IPs reach the proxy, check the effective allowlist for each route after cutover, and treat policy precedence as a review item rather than a formatting detail.

The author closes with a question that works as a checklist in itself: in a migration that looked like nothing more than a tool swap, which access rule vanished, or opened too far?