TLS Passthrough does not work

[rainest]

Problem Statement

The desired state of TLS support for TLSRoutes is:

1. a TLSRoute configured on a Gateway with listeners[].tls.mode = passthrough to result in Kong not terminating the TLS connection and forwarding the stream
2. a TLSRoute configured on a Gateway with listeners[].tls.mode = terminate to result in Kong terminating the TLS connection and forwarding the (unencrypted TCP) stream

The scope of this issue is to:

• implement (1) - as (2) works in KIC today
• implement tests for both (1) and (2)

Additional context

Broken out of #2475.

IIRC we don't do much anything with Gateway TLS mode (whether it terminates or passes through) yet, but should. We should review how, if at all, we handle it currently and add implementation for it if none exists or if the current implementation doesn't work well.

Acceptance criteria

• [ ] TLSRoute passthrough works and is documented
• [ ] an integration test for TLSRoute passthrough exists
• [ ] an integration test for TLSRoute terminated exists

[mflendrich]

Milestone 3 inclusion is conditional on this being either no-op or a low effort change. If substantial engineering work is required to make this happen, this shall be punted to Milestone 4.

[rainest]

This does not appear to be trivial. Our architecture does not easily allow feeding a property (the TLS mode) of a Listener into Route configuration. Certificates don't have this problem because they're not directly linked to individual Routes in either the spec or Kong configuration. There may also be some open questions about handling this properly on both our end and in the spec.

Currently, Routes' only interactions with Listeners is part of determining whether they can bind to the Gateways in the Route's parentRefs. We check that there is at least some Listener of the appropriate type with allowedRoutes rules that permit that Route, but do not otherwise associate them with a specific Listener. Further logic is required to find that match:

• Whether the Listener and Route have matching hostnames.
• Whether the Listener TLS mode and Route type are compatible. This part of the spec looks a bit incorrect, since it indicates that TLSRoute must use passthrough, and for terminate you instead use a TCPRoute bound to a TLS Listener. This part of the spec seems wrong, since I don't see any reason you can't use the SNI hostname to match a Route and then terminate TLS. Edit: this has come up before, but stalled: https://github.com/kubernetes-sigs/gateway-api/pull/730 -Whether the Listener port matches the optional parentReference port, if present.

So I think we need to do a fair amount of work to have getSupportedGatewayForRoute() also return the specific Listener that the Route will bind to, and from there the TLSRoute controller set some field on the store object that tells the parser translate function which protocol it should set.

Moving to milestone 4 as such.

[mflendrich]

Okay. I'm moving this to "needs AC & prioritization" because it seems that the current AC don't capture the real work to be done.

[rainest]

Nevermind, this is fine, I was confusing this with https://github.com/Kong/kubernetes-ingress-controller/issues/2474, supporting certificates at all; this is about handling passthrough or terminate. It should be ready for work with the current criteria and milestone: we initially looked at it for 2.6 but since it wasn't a simple change it didn't make the cut.

[randmonkey]

Kong supports configuring TLS passthrough in routes: https://docs.konghq.com/gateway/latest/how-kong-works/routing-traffic/#proxy-tls-passthrough-traffic. So we need to tell the parser whether a TLSRoute resource needs to configure TLS passthrough. But the settings is in listeners[].tls.mode of Gateway in its Spec.ParentRouteSpec. The possible ways to know whether we need to use TLS passthough in the kong route for TLSRoute:

• (1) run the process of finding the kong listener again from spec.parentRouteSpec
• (2) pass TLSRoute object to the cache inside KIC after updating its status with supported gateways. I prefer (2), because this method carries supported gateways of TLSRoute to cache, so we do not need to find out supported gateways again the parser.

[randmonkey]

For running integrated tests, we need a simple TLS server: https://github.com/Kong/go-echo/issues/12