Ingress-NGINX Migration IP Audit

Paste your Ingress and Service YAML to find source-IP allowlists, real-client-IP detection, and load balancer settings that silently break when you move off ingress-nginx.

Ingress & Service YAML

Runs entirely in your browser. Nothing is uploaded or stored.

Paste your Ingress and Service YAML here

0 lines · 0 chars

Findings

Paste a manifest and click Audit, or click "Load example" to see it in action.

Also see: subnet calculator · Kubernetes pod & service CIDR calculator · CNI IP pool & block size calculator · subnet overlap checker

The ingress-nginx EOL, and the controller it's easy to confuse it with

The Kubernetes SIG-Network maintainers of ingress-nginx (the project at kubernetes/ingress-nginx, one of the most widely deployed ingress controllers in the ecosystem) have announced they will stop shipping it after March 2026. That's a real deadline for a huge number of clusters — this project has been the default choice in countless getting-started guides, Helm charts, and internal platform docs for close to a decade.

The confusing part is that a completely different project shares almost the same name. F5's NGINX Ingress Controller (nginxinc/kubernetes-ingress) is a separate codebase, maintained commercially by F5/NGINX Inc., and it is not affected by the community project's EOL. If you're running F5's controller, none of this migration pressure applies to you — but it's an easy mistake to make, because both are colloquially called "the nginx ingress controller," both sit in front of nginx, and both use annotation-based configuration that looks superficially similar at a glance.

The one reliable tell is the annotation prefix: community ingress-nginx uses nginx.ingress.kubernetes.io/*, while F5's controller uses nginx.org/* (or appprotect.f5.com/* for its WAF features). This audit tool only recognizes the community project's annotation prefix — if it reports a clean pass but you know you have IP-related config, double check which controller actually owns your Ingress objects.

How to tell which one you're actually running

Don't guess from the annotation prefix alone — check the controller pod's container image directly:

kubectl get pods -n ingress-nginx -o jsonpath='{.items[*].spec.containers[*].image}'

Community project (EOL March 2026): image starts with registry.k8s.io/ingress-nginx/controller (older clusters may still show k8s.gcr.io/ingress-nginx/controller).
F5 NGINX Ingress Controller (still supported): image starts with nginx/nginx-ingress or docker.io/nginxinc/nginx-ingress.

If your namespace isn't called ingress-nginx, find the right one with kubectl get ingressclass and trace its controller field back to a Deployment.

Annotation → Gateway API / Traefik mapping, at a glance

The audit above generates this same mapping automatically for whatever you paste in, but as a static reference:

ingress-nginx annotation / field	Envoy Gateway	Traefik
whitelist-source-range	SecurityPolicy + clientCIDRs	IPAllowList middleware
denylist-source-range	SecurityPolicy, Allow + Deny rules	IPAllowList + rejectStatusCode
enable-real-ip / proxy-real-ip-cidr	ClientTrafficPolicy.clientIPDetection	entryPoints.forwardedHeaders.trustedIPs
ssl-passthrough	TCPRoute/TLSRoute + PROXY protocol	PROXY protocol on entrypoint
limit-rps / limit-rpm / limit-connections	BackendTrafficPolicy.rateLimit	RateLimit + ipStrategy
Service.loadBalancerSourceRanges	Same field, set on new Service	Same field, set on new Service
Service.externalTrafficPolicy: Local	Same field, set on new Service	Same field, set on new Service

FAQ

Is this the same ingress-nginx that's reaching end of life?

Only if your controller image comes from registry.k8s.io/ingress-nginx/controller (or the older k8s.gcr.io/ingress-nginx path) — that's the community project (kubernetes/ingress-nginx) with an announced EOL of March 2026. F5's NGINX Ingress Controller (nginxinc/kubernetes-ingress) is a different codebase, commercially supported, and unaffected by this EOL. Check your controller pod's image before doing anything else.

Does this tool cover Helm values or the ingress controller ConfigMap?

No — it only scans the Ingress and Service YAML you paste in. Several of these settings (real-IP detection in particular) are often set globally in the ingress-nginx ConfigMap or a Helm values.yaml rather than per-Ingress annotation, so check both of those manually even if this tool reports a clean pass.

Why isn't there a 1:1 mapping for whitelist-source-range?

Because ingress-nginx bakes IP allow-listing into the ingress controller's own request-handling logic as an annotation, while Gateway API implementations treat authorization as a separate, composable policy object attached to a route. That's a deliberate architectural difference in Gateway API — access control isn't part of the core routing spec — not a missing feature in Envoy Gateway or Traefik.

What should I do with a HIGH severity finding?

Recreate it explicitly on the new controller before cutting traffic over, then verify it under load — none of these settings fail loudly. A missing IP allowlist just serves traffic to everyone; broken real-IP detection just makes every downstream IP-based decision silently see the load balancer's address instead of the client's. Test each HIGH finding against a real client IP, not just a config diff.