GKE Gateway adds native CORS support, moving cross-origin policy to the load balancer

What happened

Google has shipped a Preview release of native CORS support for GKE Gateway and Inference Gateway, according to a post on dev.to. The feature closes one of the most commonly cited gaps for teams migrating from Ingress-Nginx to the Kubernetes Gateway API, where cross-origin policy previously had to live inside application code.

Browsers enforce the Same-Origin Policy by default, blocking scripts from reading responses served by a different origin. Since most modern applications — single-page apps, mobile clients, embedded widgets and increasingly AI inference endpoints — need to communicate across domains, they rely on Cross-Origin Resource Sharing to open those paths safely. On Ingress-Nginx, teams handled this with controller annotations such as the enable-cors annotation. The Gateway API had no equivalent, which made the missing capability a recurring complaint during migrations. The new release adds a CORS filter to GKE's Gateway and Inference Gateway implementations, defined declaratively inside HTTPRoute manifests.

Why handle CORS at the edge

The dev.to post identifies three problems with handling CORS per-service. First, every backend — whether Node.js, FastAPI, Spring or an inference server like vLLM — needs its own middleware to inspect incoming headers and answer preflight requests. Second, preflight OPTIONS calls consume memory, CPU and bandwidth in application containers even though they carry no business payload. Third, when dozens of microservices each maintain their own policy, small differences in allowed headers or origin validation drift apart over time, creating both security holes and broken client integrations.

With the new filter, Google Cloud Load Balancing terminates OPTIONS requests at the edge and injects the Access-Control-Allow-Origin, Access-Control-Allow-Methods and Access-Control-Allow-Headers responses itself. Backends only see validated requests, which strips boilerplate from code and cuts protocol-negotiation overhead.

How the filter is configured

CORS is configured as a filter within the rules section of an HTTPRoute, following the open-source Gateway API specification. The available knobs include:

• allowOrigins: explicit URLs, wildcard patterns such as a partner subdomain match, or a catch-all asterisk
• allowMethods: permitted HTTP verbs, or a wildcard for all of them
• allowHeaders: request headers clients may send
• exposeHeaders: response headers the browser makes visible to scripts
• allowCredentials: toggles whether cookies and authentication headers can accompany requests
• maxAge: how many seconds a browser may cache the preflight response, defaulting to five seconds and sharply reducing repeat OPTIONS traffic

Security pitfalls with wildcards

The post highlights a sharp edge in how wildcards interact with credentials. Browsers reject credentialed responses when Access-Control-Allow-Origin is a literal asterisk. But GKE Gateway handles wildcard origin patterns by dynamically matching and reflecting the requesting origin, so the browser sees an explicit origin and accepts the response.

That means configuring a catch-all origin together with allowCredentials enabled would let an arbitrary website read authenticated user responses. The recommended practice for authenticated APIs is to define explicit domain lists rather than broad wildcards.

Availability and limits

The Preview covers single-cluster GKE Gateway deployments across three GatewayClasses: gke-l7-rilb (regional internal Application Load Balancer), gke-l7-regional-external-managed and gke-l7-global-external-managed. Inference Gateway deployments also gain the filter, allowing browser-based chat interfaces and client SDKs to query served models directly across origins.

Several constraints apply. Multi-cluster gateways, the gke-l7-gmc-* classes, do not support the CORS filter yet. A CORS filter cannot be combined with a RequestRedirect filter in the same route rule. And wildcard origins consume regular-expression quota on the underlying Cloud Load Balancing URL maps: on the global external class the limit is one regex per Gateway listener, and wildcard origins cannot be combined with PathPrefix matches at all, while the regional classes allow up to five regexes per hostname. Exact origins and catch-all entries do not count against these quotas.

Why it matters

CORS is a small piece of configuration that has historically caused outsized pain: it is scattered across services, easy to get wrong and expensive to debug. Moving it into the routing layer lets platform teams centralise cross-origin policy the same way they already centralise TLS and routing rules, remove protocol boilerplate from backend code, and stop paying container compute costs for preflight chatter. For teams partway through an Ingress-to-Gateway-API migration, this removes one of the last functional reasons to keep the legacy controller around. The Preview status and the multi-cluster gap suggest caution for production rollouts, but the direction is clear: cross-origin policy is becoming infrastructure configuration rather than application code.