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

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[shaneutt]

We talked about this on the sync today, this PR has some bearing on this: #3458

[chifu1234]

@shaneutt thxs for the update 😄 ! So if I understand it correctly with #3458 & #2111 it will be possible to configure TLSRoute in terminate mode. The GW then still is handling the TLS termination, but it will route according to the SNI and not "HTTP Host Header".

[youngnick]

Yes, that's correct. Note that we'll need to add conformance tests, a feature name, and so on to consider this fully ready to go, but yes.

[mlavacca]

Yep, as @youngnick confirmed, we are willing to support Terminate for TLSRoute with #3458. However, we cannot consider it ready until conformance tests are added for this feature. An issue already exists #3466 and is on my todo list.

[mlavacca]

/triage accepted

[mlavacca]

/remove-lifecycle rotten