Gep 2907 update - TLS mode and allowed routes #3458
Conversation
|
/cc @candita @youngnick |
|
Yeah, this accurately conveys the current state, although I think that we do not have any conformance testing at all about TLSRoute with Terminate behavior. Edit LGTM, but I'd like to hear from others too. |
Yep, I just created #3466 to track conformance tests with |
geps/gep-2907/index.md
Outdated
| > [!NOTE] | ||
| > When the traffic is routed to the backend via `TCPRoute`, the packets | ||
| > are left untouched by the gateway. In order to terminate the TLS connection to | ||
| > the gateway and forward the traffic unencrypted to the backend, a `TLSRoute` configured | ||
| > with `Terminate` as TLS mode has to be used. |
There was a problem hiding this comment.
This is a bit confusing to me. Why does the route type matter here? In the case of TLS passthrough, it seems like you'd have two options if you wanted to use SNI to select the backend:
- Multiple Listeners with different hostnames specified
- One Listener with multiple TLSRoutes attached, each specifying a different SNI
On the other hand, if you wanted to do TLS termination, you'd have the following options:
- Route based on HTTP attributes: HTTPRoute
- Send all traffic attached to a Listener to the same set of backends: HTTPRoute or TCPRoute
Writing that all out makes me continue to think that our <L7 route types may not be entirely necessary (x-ref the related doc).
There was a problem hiding this comment.
There is a third plausible option, you could do "One Listener with multiple TLSRoutes attached, each specifying a different SNI" but still use terminate. I mean hypothetically, I believe we say this isn't the semantics of the routes.
There was a problem hiding this comment.
@howardjohn that's a good point, it's certainly possible with the API surface we currently have, do you know of any common use cases for that?
There was a problem hiding this comment.
This is good discussion, I have a question: In the case of encrypted L4 traffic, why users should use TCPRoute with TLS Terminate overTLSRoute? This is one of the main aspects I'm trying to capture with this GEP update. The assumption I'm making is: in case you need TLS, use either HTTPRoute or TLSRoute, depending on your needs and use-case.
There was a problem hiding this comment.
So why do we need both TCPRoute and TLSRoute? Could TCPRoute just have optional TLS config? It's a bit of a sidebar, but the omission. Of TCPRoute here prompts the question I think
There was a problem hiding this comment.
I get your point, and it makes a lot of sense to me. Adding TCPRoute to the list of routes for which TLS with terminate is allowed:
| Protocol | Routes | TLS Terminate | TLS Passthough |
|---|---|---|---|
| HTTP | HTTPRoute | no | no |
| HTTPS | HTTPRoute | yes | no |
| GRPC | GRPCRoute | yes | no |
| TLS | TLSRoute | yes | yes |
| TCP | TCPRoute | yes | no |
| UDP | UDPRoute | no | no |
There was a problem hiding this comment.
Just catching up on this - @mlavacca's updated table in the previous comment LGTM, thanks for all the great discussion on this thread!
There was a problem hiding this comment.
yep, addressed in 358b483. Closing the thread
There was a problem hiding this comment.
Thanks @mlavacca! I ended up looking at the PR, forgetting the context and having to reread this thread to understand how we got to this conclusion. Do you mind adding some of this context/rationale in the PR?
There was a problem hiding this comment.
Yep, I've added some context to the PR description.
geps/gep-2907/index.md
Outdated
| > [!NOTE] | ||
| > When the traffic is routed to the backend via `TCPRoute`, the packets | ||
| > are left untouched by the gateway. In order to terminate the TLS connection to | ||
| > the gateway and forward the traffic unencrypted to the backend, a `TLSRoute` configured | ||
| > with `Terminate` as TLS mode has to be used. |
There was a problem hiding this comment.
So why do we need both TCPRoute and TLSRoute? Could TCPRoute just have optional TLS config? It's a bit of a sidebar, but the omission. Of TCPRoute here prompts the question I think
9fa750f to
358b483
Compare
|
Thanks @mlavacca! LGTM other than my last comment. |
|
This LGTM as well - although I think that we should be clear that none of the new things we've added are final until we have conformance tests to lock in the required behavior. |
Signed-off-by: Mattia Lavacca <[email protected]>
Signed-off-by: Mattia Lavacca <[email protected]>
Co-authored-by: Keith Mattix II <[email protected]> Co-authored-by: Mike Morris <[email protected]>
The table related to protocol-supported routes-TLS mode has been improved to address reviews' comments. Signed-off-by: Mattia Lavacca <[email protected]>
Signed-off-by: Mattia Lavacca <[email protected]>
358b483 to
8ab1bc2
Compare
|
It took me some time, but I eventually managed to get back to this one and address the last comments. Please take another look. |
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: howardjohn, mlavacca, shaneutt The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
What type of PR is this?
/kind gep
What this PR does / why we need it:
This PR supersedes #3190.
This PR updates GEP-2907 with two different aspects:
A key takeaway and most discussed point of this PR is allowing TLS termination for TLSRoute. A lot of context can be found in #2111 and #3458 (comment). The needs of this feature boils down to "I want to route L4 and L7 traffic on the same listener, and I want to route L4 traffic based on hostname."
This PR intends to reach an agreement that will make #2111 and #1474 addressable.
Which issue(s) this PR fixes:
Does this PR introduce a user-facing change?: