GEP: TLS ALPN Routing

[dboslee]

What would you like to be added: A way to configure routing decisions based on the application protocols present in the TLS client hello of a TLS connection.

The TLSRoute is a good candidate for supporting this as it is a similar feature to SNI routing which is already handled by TLSRoute. Both SNI and ALPN are present in the TLS client hello and allow for TLS passthrough.

The initial discussion on this subject is here.

Why this is needed:

This would allow service owners to route to different backends behind a single domain based on the protocol the client supports.

For example if you have http/2 and mqtt clients connecting to example.com:443 you could use the application protocols in the TLS client hello to route these clients to different backends that are able to handle the respective protocol.

[shaneutt]

Sounds like this would be reasonable to add. The next logical step would appear to be more GEP work so we can build consensus on how this would work:

/triage accepted /kind gep

However this doesn't appear to be something we must have for GA, which is our current main focus so we consider it a low priority until GA is complete:

/priority backlog

[ibilalkayy]

The discussion around adding support for routing decisions based on the application protocols present in the TLS client hello of a TLS connection is ongoing. The proposal suggests extending the TLSRoute to handle this feature as it is similar to SNI routing, which is already supported.

The addition would allow service owners to route to different backends behind a single domain based on the protocol the client supports. For example, if you have http/2 and mqtt clients connecting to example.com:443, you could use the application protocols in the TLS client hello to route these clients to different backends that can handle the respective protocol.

The initial discussion on this subject is available in Issue #1683, and a more detailed GEP (Gateway Enhancement Proposal) is available in Issue #1958.

Although the proposal seems reasonable, the main focus for the Kubernetes community is currently on Gateway API reaching GA (General Availability). Therefore, the priority of this feature is considered low until GA is complete.

[dboslee]

@ibilalkayy As an external contributor I have time to work on the GEP and implementation of this feature but understandably this still requires time from maintainers to review and give feedback. Should I expect feedback on #1974 time permitting, or will any attention on this be held off until after GA?

[shaneutt]

@ibilalkayy As an external contributor I have time to work on the GEP and implementation of this feature but understandably this still requires time from maintainers to review and give feedback. Should I expect feedback on #1974 time permitting, or will any attention on this be held off until after GA?

You can expect some feedback in the meantime, it's just a matter of all of us who volunteer on this project having limited bandwidth between now a GA, and GA related things will get the highest priority. To help get attention, smaller iterations introducing only bite-sized chunks of a proposal at a time (e.g. just providing a tldr and some goals) can be helpful which looks like the approach you've taken here. I'll make some time personally to look it over soon thank you for taking the time to submit it! :vulcan_salute:

[k8s-triage-robot]

This issue has not been updated in over 1 year, and should be re-triaged.

You can:

• Confirm that this issue is still relevant with /triage accepted (org members only)
• Close this issue with /close

For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/

/remove-triage accepted

[hbobenicio]

Just as an additional use case for this, ALPN support for gateway listeners or tlsroutes would be really nice for serving north/south traffic for postgres workloads.

Postgres 17 is using a custom string for ALPN called "postgresql".

So Gateways with tls listeners + tlsroutes trying TLS Mode as Terminate should be able to respond for ALPN requests for this custom query. So this flexibility comes in handy in this case (tls termination for upstream workloads running custom ALPN protocols).