System and roles
Gateway API defines resources such as GatewayClass, Gateway, listeners, routes, and backend references. Its role model separates infrastructure ownership, cluster operation, and application route ownership. Implementations realize the data plane.
Attachment and flow
A Gateway selects a class and declares listeners. Route resources attach only when namespace, kind, hostname, section, and allowed-route rules permit them. Backend references select services. Policy attachments can add implementation-specific or standardized behavior at defined targets.
Access boundary
Treat route attachment, cross-namespace references, certificate use, policy attachment, and controller identity as control-plane authorization. Treat the realized listener and backend path as data-plane enforcement. Verify both desired and effective state.
Failure and residual risk
An allowed cross-namespace reference can cross tenant boundaries. Conflicting routes or policy can attach unexpectedly. Controller compromise affects many gateways. Another Service or load balancer can bypass the Gateway. Gateway routing does not replace application authorization.
Pomerium boundary
Pomerium can be deployed in Kubernetes and can participate in documented ingress and routing patterns. Operators must use the current Pomerium and Gateway API support matrix. They own resource permissions, controller trust, attachment policy, backend isolation, and application authorization.
Evaluation checklist
- Who owns GatewayClass, Gateway, Route, policy, and backend resources?
- Which attachment and cross-namespace rules permit the route?
- Does effective status match reviewed desired state?
- Can another Service, ingress, or load balancer reach the backend directly?
- Which access policy and application action remain outside Gateway API routing?
