Support for TLS Certificate Management in Gateway API TLSRoute

[chifu1234]

Description:*
The current Gateway API specification does not seem to provide a straightforward way to manage TLS certificates and handle SNI-based routing without pre-defining certificates in the Gateway resource. This limits the flexibility and scalability of managing certificates, particularly in environments where IPs are limited.

Problem Statement:

I am trying to set up a Gateway that:

- Does not contain any pre-defined certificates.
- User can add TLSRoutes and let the Gateway API handle the TLS Termination
- Limited IP availability environment or cost intense environment

Currently, the Gateway API does not support defining certificate within the TLSRoute specification. This means in order for user the

Proposed Solution:

TLS certificate management directly within TLSRoute.
add TLSRoute.spec.tls.certificateRefs

[youngnick]

Thanks for logging this issue @chifu1234.

Currently, the Gateway API does not support defining certificate within the TLSRoute specification. This means in order for user the
It seems like something got cut off here?

I think it's important to clarify what TLSRoute is intended for - it's intended for use cases where you are only using TLS properties (currently only the SNI is available) to choose which backend to forward to. We've discussed Terminated TLSRoutes (in #2111), but we haven't actually implemented anything. Note that in that case, the expected behavior would be a decrypted TCP stream directed towards the chosen backend. No HTTP routing would be possible.

If you want to use HTTP information for routing, the correct resource would be HTTPRoute, with TLS termination.

All of that said, we built the current design with the assumption that people would either:

• use a wildcard TLS certificate at the Gateway level, with subdomains on the TLSRoute (or HTTPRoute), so a certificate of *.example.com on the Gateway, and TLSRoutes of foo.example.com and bar.example.com
• or write a controller to look for HTTPRoutes or TLSRoutes trying to attach, and edit the Gateway accordingly.

It's important to remember that we don't mandate any checking of the served certificates, which means that solutions that allow users to specify their own TLS certificates are trusting those users to do the right thing with generation. What would happen if one Route or similar defines a TLS certificate for supersecret.example.com and someone else issues one for *.example.com, even though their domain name in the Route is set to totallynotahacker.example.com?

I think that what would happen there is very dependent on exactly how the Gateway implementation handles TLS certificates and builds the routing rules for TLS.

Edge cases like this are why we find it's better to go slowly and carefully, making sure we cover edge cases like that in the specification, and why, after long discussion, we decided not to put TLS certificates directly in Routes - either TLSRoute or HTTPRoute.

[shaneutt]

/triage needs-information

[candita]

@chifu1234 Does mutual tls configuration in BackendTLSPolicy help your case: https://github.com/kubernetes-sigs/gateway-api/blob/main/geps/gep-3155/index.md?

[dghubble]

related #3418