The v1.5 and v1.6 copies of networking/gateway-api.md describe the route-hostname admission policy without mentioning that it admits a route declaring no spec.hostnames at all. The CEL that ships in both releases contains that branch, so the pages describe a narrower guarantee than the one the cluster enforces.
Mechanism
The policy's expression opens its hostname test with a disjunct that passes when the field is absent, so a route with no spec.hostnames is admitted rather than rejected. A route without hostnames is not inert: Gateway API attaches it to every listener whose allowedRoutes admits it, and it then answers for whatever hostname that listener carries.
The pages present the policy as binding a tenant's routes to its own apex. That is what the policy does for a route that declares hostnames. For a route that declares none, the apex rule never runs.
Impact
Documentation-only, and conditional in practice: no tenant identity holds any verb in the gateway.networking.k8s.io group, so a tenant cannot create such a route today. The cost is that a reader auditing the security model on a released version gets a guarantee stated without its precondition, and the precondition is the interesting half — the layer confines routes that name hostnames, and the confinement of everything else rests on RBAC rather than on this policy.
The next copy of the page now states this. The two released copies do not, and the same CEL ships in both of those releases.
Fix shape
Add the same sentence to the Layer 5 description on both released pages: the policy admits a route that declares no hostnames, and what keeps such a route out of a tenant namespace is the absence of route RBAC rather than this layer.
Verify against each release tag before copying — this repository's released pages have needed three different answers for three claims in one recent change, so a blanket backport is not safe by default. Here the CEL is the same in both, but that is a fact to check rather than assume.
The v1.5 and v1.6 copies of
networking/gateway-api.mddescribe the route-hostname admission policy without mentioning that it admits a route declaring nospec.hostnamesat all. The CEL that ships in both releases contains that branch, so the pages describe a narrower guarantee than the one the cluster enforces.Mechanism
The policy's expression opens its hostname test with a disjunct that passes when the field is absent, so a route with no
spec.hostnamesis admitted rather than rejected. A route without hostnames is not inert: Gateway API attaches it to every listener whoseallowedRoutesadmits it, and it then answers for whatever hostname that listener carries.The pages present the policy as binding a tenant's routes to its own apex. That is what the policy does for a route that declares hostnames. For a route that declares none, the apex rule never runs.
Impact
Documentation-only, and conditional in practice: no tenant identity holds any verb in the
gateway.networking.k8s.iogroup, so a tenant cannot create such a route today. The cost is that a reader auditing the security model on a released version gets a guarantee stated without its precondition, and the precondition is the interesting half — the layer confines routes that name hostnames, and the confinement of everything else rests on RBAC rather than on this policy.The
nextcopy of the page now states this. The two released copies do not, and the same CEL ships in both of those releases.Fix shape
Add the same sentence to the Layer 5 description on both released pages: the policy admits a route that declares no hostnames, and what keeps such a route out of a tenant namespace is the absence of route RBAC rather than this layer.
Verify against each release tag before copying — this repository's released pages have needed three different answers for three claims in one recent change, so a blanket backport is not safe by default. Here the CEL is the same in both, but that is a fact to check rather than assume.