search

kubernetes-sigs / external-dns

Configure external DNS servers (AWS Route53, Google CloudDNS and others) for Kubernetes Ingresses and Services
Apache License 2.0
7.74k stars 2.58k forks source link

Support hostnames in K8S Gateway #4402

Open costinm opened 7 months ago

costinm commented 7 months ago

What would you like to be added:

Use hostnames from the Gateway CR.

Why is this needed:

Current API supports using hostnames in HttpRoute - however users who want more security would define them in Gateway and specify allowRoutes - with the namespace where the Gateway is defined having stricter RBAC.

It's a relatively small change.

abursavich commented 4 months ago

External-DNS has always respected Gateway Listener Hostname and AllowedRoutes. Do you have a case where this isn't working?

https://github.com/kubernetes-sigs/external-dns/blob/v0.14.2/source/gateway.go#L328-L358

gcs278 commented 3 months ago

@costinm Are you asking to use the Gateway CR as an External DNS source?

@abursavich do you know if that ever been requested yet or discussed? I'm curious about the situation in which hostnames are specified on the Gateway Listener, but not in the xRoute. I don't believe External DNS has a way to create records using the Gateway CR, but it's a valid GWAPI configuration.

Gateway Listener Merging, currently being discussed in https://github.com/kubernetes-sigs/gateway-api/pull/3213, may have some implications for using Gateways Listener as a source.

abursavich commented 3 months ago

According to the GW-API spec, hostnames are essentially the intersection or overlap of those allowed by the Route and those allowed by the Listener. I believe this is what is being requested, but this is what the External DNS implementation has always done.

costinm commented 2 months ago

Last time I checked, defining the hostname in Gateway CR and not in route didn't work.

If gateway owner created the Gateway object and no route is present - I think DNS should still reflect the name. The routes may come and go as apps are deployed - for example certmanager may create a route to solve the challenge, remove it after. And once the user has certs they may deploy apps including HttpRoutes that attach to the internet gateway without knowing the hostname.

AFAIK routes don't need to include the hostname.

abursavich commented 2 months ago

I see what you mean. The implementation does require the combination of Gateway Listeners and Routes. It won't use a Gateway without a Route.

I still think it's reasonable to be serving a domain (with a Gateway Listener and Route) before creating a record for it. The intent is very clear at that point. Otherwise we're making assumptions that may not be true.

As a concrete example, I wouldn't want to create wildcard records just because a Gateway Listener includes some wildcard (e.g. *.foo.com). It might be the Gateway creator's intent to allow users to create specific routes (e.g. bar.foo.com), but they may not actually want a wildcard record. If they add a matching wildcard Route, then we create the wildcard record.

Miciah commented 1 month ago

As a concrete example, I wouldn't want to create wildcard records just because a Gateway Listener includes some wildcard (e.g. *.foo.com).

I'm actually interested in exactly this. In my situation, the gateway represents a proxy with an associated domain and load-balancer. As the gateway owner, I want a wildcard DNS record for that domain, pointing to that proxy/load-balancer. Route owners can attach routes with host names that fall under the domain name. As a gateway owner, I want a single wildcard DNS record for the gateway itself, not a DNS record for each route.