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! 🖖