-
Notifications
You must be signed in to change notification settings - Fork 498
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Gep 2907 update - TLS mode and allowed routes #3458
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: Mattia Lavacca <[email protected]>
Signed-off-by: Mattia Lavacca <[email protected]>
/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 |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: 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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @mlavacca! Sorry I missed this one!
| `HTTPRoute` | yes | no | | ||
| `GRPCRoute` | yes | no | | ||
| `TLSRoute` | yes | yes | | ||
| `TCPRoute` | no | no | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not TLS with passthrough here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you are doing TLS passthrough and a TCPRoute, its no different than just TCP + TCPRoute. Unless you want to say we allow TLSRoute and TCPRoute to bind to the same listener here, then you would have something like
- Highest priority: TLS route matching SNI
- Lowest priority: the (at most 1) TCP route
?
> [!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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
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:
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?: