How do you let tenants manage their own certificates?

[kbsquared]

Currently on ingress, we use cert manager and external dns to allow cluster tenants to manage their own DNS and certificates for whatever hostnames they need in their namespace. The cluster operators manage the ingress controller. Is there a way for me to enable this with gateway api? Not excited about adding hostnames and tls configuration to the gateway everytime an app team wants to change something.

Thank you for any advice/input.

[mpstefan]

Are your hostnames completely unique, or do they follow a wildcard pattern? In the latter case, you could setup a listener with a wildcard hostname (i.e. *.vehicles.coolcarcompany.com). You could also supply a wildcard cert to cover each case.

If not, or you don't want to split your teams into their own subdomains, how do you configure your Ingress today to accept any hostname to any service? As I understand, you'd still need configuration on the Ingress to direct a new hostname to a service. NGINX Gateway Fabric is compatible with cert manager - so I would expect any setup you have working with Ingress for certificate management should look pretty similar.

There has been some discussion on allowing app teams to control hostnames within the Gateway API community, BUT there shouldn't be anything possible in Ingress that is not possible with Gateway API, we'd just have to see how your Ingress is setup.

[kbsquared]

Thank you for the response. I'm trying to stay away from wildcard records. We have a naming standard of service-namespace.example.domain.com. Currently we use the Certificate CRD with cert manager. The application team creates that themselves. They also create the ingress themselves to accept their hostname using their cert. No wildcards are in use.

[mpstefan]

Got it. You CAN route a new hostname from the Route object, BUT if you need to add a new certificate for a unique hostname, that has to be added to the Gateway. Right now, there is integration with cert-manager (explained here for NGF), but with your use case of a completely unique hostname each time, there isn't a way with the Gateway API standard to only use cert-manager to update the Gateway with a new listener for every hostname you want to add.

In this case, it might be a lot easier to just allow access to the Gateway so teams can update the listeners themselves, but you do run the risk of misconfiguration affecting everyone on the cluster.

Alternatively, you could do also do strategy similar to Ingress - create a new Gateway for each team to manage themselves. At this point, you'd need multiple installations of NGF to make this work, but in 2.0 (should be coming ~May) you'll just be able to declare multiple Gateway objects with the same installation.

I think this problem is running up against the role-oriented design of Gateway and crossing into the cluster operator space, which the Gateway API was designed against. You can still make it work, but not as intended and certainly is not very straightforward. I hope that helps!