Gateway API changes security mainly through separation of roles and explicit attachment rules. A Gateway accepts routes from its own namespace by default, and cross-namespace routes need configuration. Ingress packs everything into one resource plus controller specific annotations, and the Ingress API is frozen.
The two models side by side
| Question | Ingress | Gateway API |
|---|---|---|
| Who owns what | One resource mixes listener, TLS and routing | GatewayClass, Gateway and routes are separate kinds, modeled on roles |
| Extra features | Controller specific annotations | Expressed in the API, such as header matching and traffic weighting |
| Which namespaces can attach | Resource lives in the app namespace and the controller picks it up | A Gateway can filter routes per listener, and by default accepts routes only from its own namespace |
| API status | Frozen per the Kubernetes docs | Stable kinds include GatewayClass, Gateway, HTTPRoute and GRPCRoute |
| Portability | TLS features differ between controllers | Defined as custom resources supported by many implementations |
Why roles matter for security
The Gateway API documentation names three roles: an infrastructure provider, a cluster operator and an application developer. The cluster operator owns the Gateway, which defines the network endpoint and its listeners. Application developers own routes in their own space and attach them to a Gateway the operator allows.
That split mirrors least privilege. An app team can publish a route for its service without being able to change the listener, certificates or which hostnames the gateway answers for. In Ingress, whoever can create an Ingress object can often affect edge behavior, and controller annotations can add powerful configuration. The Ingress NGINX retirement notice itself calls out configuration injection through snippets annotations as a serious flaw. See what to do about Ingress NGINX.
Settings to review in Gateway API
- allowedRoutes. Keep listeners limited to the namespaces that need them, rather than opening to all.
- Hostnames per listener. Pin a listener to a hostname so a route cannot claim someone else's.
- TLS on listeners. Terminate with certificates managed by the operator role; see the TLS termination guide.
- RBAC on route objects. Decide who can create HTTPRoute and GRPCRoute in each namespace, since creating a route is how traffic gets exposed.
Does moving make you safe?
No. A new API removes some footguns, but it does not secure the backend, the controller's own code or your RBAC. Implementations vary, and a controller is still software with vulnerabilities and updates to apply. Treat the move as a chance to redo exposure review, not a guarantee.
A migration lens
- List every public hostname and path today.
- Decide which team should own each Gateway.
- Restrict who may attach routes to production Gateways.
- Re-test authentication and rate limiting at the edge after the change.
- Keep the controller image and version in your inventory and patch it.
Quick check
Is the Ingress API removed?
Per the Kubernetes docs the Ingress API is frozen, meaning it is stable but not receiving new features. The Ingress NGINX controller, a separate project, is the one being retired.
Can a team attach a route to any Gateway?
By default a Gateway accepts routes only from its own namespace. Allowing other namespaces requires configuring allowedRoutes.
Does Gateway API replace network policy?
No. It controls how traffic enters and is routed. Network policy still restricts which workloads can talk to each other.
Where Safeguard fits
Safeguard's asset discovery and SBOM generation help keep the controller and gateway components you run in your inventory, so a new advisory can be matched to them quickly. A free scan shows how that looks for your own code.
Sources
Last reviewed: 19 October 2026.
