Configurable HTTPRoute fallback to Gateway listener.hostname

[fredrikgh]

Currently, the HTTPRoute source may fallback to using the attached Gateway listener.hostname if no other target is found. This can be problematic if that hostname was never intended to become a DNS record.

What would you like to be added:

Have the final fallback in HTTPRoutes target identification, If no endpoints were produced by the previous steps, each attached Gateway listener will use its hostname, if present., configurable. Not sure at what level, or multiple.

Why is this needed:

When sourcing from gateway api resources and specifying hostname(s) on your Gateway, you currently have to accept that these may become DNS entries. Even if you expect HTTPRoute or other "child" resources to set their own hostnames - should a configuration error on a Gateways child resource cause an unavoidable DNS "leak" up the tree?

There are multiple reasons for specifying listener.hostname without any DNS intentions, e.g. cert management.

Example use case:

Deploying a cluster-wide gateway for all inbound traffic, which terminates TLS. You may want generic listeners, but still specify hostnames to e.g. enable the cert-manager auto generated cert (which requires hostname). To achieve this, you may wildcard the Gateway listener hostname (*.foo.com) and allow HTTPRoutes to register specific records (bar.foo.com). If the HTTPRoute fails to specify a hostname, the wildcard entry is registered which may have unintended consequences.

[Dadeos-Menlo]

May I enquire as to whether the issue described only pertains to wildcard hostnames associated with Gateway listeners?

The closest current unit-test case appears to be TestGatewayHTTPRouteSourceEndpoints/WildcardInRouteAndGateway, which states that for an HTTPRoute with hostname *.example.internal and a Gateway listener with hostname *.example.internal a DNS record with name *.example.internal should be generated. I find this assertion surprising; I wasn't aware that a DNS record with name *.example.internal. was valid, although my experimentation with Google's CloudDNS permitted creation of such a named record.

The example use case described would involve a similar scenario to the identified unit-test case, except the HTTPRoute would have no hostname specified. In such a scenario a DNS record with name *.example.internal would also be generated by the current implementation.

I'm trying to understand why all hostnames, as deduced via the gwMatchingHost(…) function, with a prefix of *. are not discarded, which might be achieved by the following change:

diff --git a/source/gateway.go b/source/gateway.go
index 5d847499..342c9c18 100644
--- a/source/gateway.go
+++ b/source/gateway.go
@@ -349,7 +349,7 @@ func (c *gatewayRouteResolver) resolve(rt gatewayRoute) (map[string]endpoint.Tar
                                        continue
                                }
                                host, ok := gwMatchingHost(gwHost, rtHost)
-                               if !ok {
+                               if !ok || strings.HasPrefix(host, "*.") {
                                        continue
                                }
                                override := getTargetsFromTargetAnnotation(gw.gateway.Annotations)

[fredrikgh]

I'm trying to understand why all hostnames, as deduced via the gwMatchingHost(…) function, with a prefix of *. are not discarded [...]

Wildcard entries are valid and useful, discarding them is a bad idea.