Fix inconsistencies on TLSRoute documentation #4139
Conversation
k8s-ci-robot
added
release-note-none
|
/cc @mikemorris |
Co-authored-by: Blake Covarrubias <blake.covarrubias@gmail.com>
| |HTTPRoute| Layer 7 | Anything in the HTTP Protocol | Terminated only | HTTP and HTTPS Routing| | ||
| |TLSRoute| Somewhere between layer 4 and 7| SNI or other TLS properties| Passthrough or Terminated | Routing of TLS protocols including HTTPS where inspection of the HTTP stream is not required.| | ||
| |TCPRoute| Layer 4| destination port | Passthrough or Terminated | Allows for forwarding of a TCP stream from the Listener to the Backends | | ||
| |TCPRoute| Layer 4| destination port | Terminated | Allows for forwarding of a TCP stream from the Listener to the Backends | |
There was a problem hiding this comment.
I think this is correct and in alignment with the current docs for https://gateway-api.sigs.k8s.io/reference/spec/#tlsmodetype and clarifications in https://gateway-api.sigs.k8s.io/geps/gep-2907/#6-configure-tls-mode.
I believe TCPRoute can still be attached to a listener omitting any TLS configuration, which can be an alternative means of opaque passthrough for TLS connections (the gateway has no understanding that the TCP connection it's proxying may be TLS) where routing based on hostname is not needed.
There was a problem hiding this comment.
sorry Mike, your point here is that we should keep the Passthrough, or that this change is fine?
There was a problem hiding this comment.
there is no need to support TCPRoute with mode: Passthrough. When a TCPRoute is used, the GW Listener should use protocol: TCP.
- A TCP Listener passes TLS traffic through by default,
mode: Passthroughis unnecessary. mode: Passthroughis only needed when you need to match TLS-specific metadata (e.g. usingTLSRoute) without offloading the TLS.
There was a problem hiding this comment.
@rikatz Change is good as is.
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: mikemorris, rikatz The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
Thanks @mikemorris , I have fixed/tried to reword, let me know if this works |
Co-authored-by: Mike Morris <mikemorris@users.noreply.github.com>
|
sounds good, commited here! thank you! |
| `BackendTLSPolicy` can be used in this case to re-encrypt the connection using different | ||
| set of certificate authorities, SNI and other configurations. |
There was a problem hiding this comment.
BackendTLSPolicy doesn't cover TLSRoutes at this point in time. I think we'd need to discuss an addition to the enhancement.
There was a problem hiding this comment.
I think an update to BackendTLSPolicy may be helpful to clarify this, but the intent with this phrasing is just being explicit about where TLSRoute encryption stops:
- in Passthrough mode, TLSRoute is encrypted from the client all the way to the workload (and remains as a non-goal/out-of-scope/undefined for BackendTLSPolicy)
- in Terminate mde, TLSRoute is encrypted from the client to the gateway, and how traffic is passed from the gateway to the backend workload is an implementation detail.
BackendTLSRoute was just mentioned as an example of how the gateway to workload traffic would not necessarily be unencrypted (some mesh-integrated gateways have alternative means of encrypting traffic from an ingress to backend workload), not imply any sort of interoperability or support, and it should be fine to rephrase or remove this mention if it's introducing unnecessary confusion.
There was a problem hiding this comment.
+1, maybe we can remove any mention to BackendTLSPolicy right now, and once the TLSRoute is defined we can extend BackendTLSPolicy GEP to support TLSRoute when terminating
There was a problem hiding this comment.
+1, we should remove the BackendTLSPolicy for now.
For TLSRoutes, the focus should be on the client-to-gateway connection. The gateway-to-backend connection is a separate concern and is out-of-scope for TLSRoutes, as its configuration can vary based on specific needs.
For example, even with end-to-end client-to-backend TLS (aka TLS Passthrough), a mesh deployment might still choose to re-encrypt internal traffic (see diagram below). TLSRoutes have little to none impact on gateway-to-backend connections.
| payload. In this latter case, the gateway may be configured to re-encrypt | ||
| the traffic before sending it on to the backend, such as when a | ||
| `BackendTLSPolicy` has been applied to the destination. |
There was a problem hiding this comment.
What type of PR is this?
/kind documentation
What this PR does / why we need it:
TLSRoute documentation has some inconsistencies between what is supported, and how it is supported. This PR fixes these inconsistencies on the documentation.
Which issue(s) this PR fixes:
Fixes #1474
Does this PR introduce a user-facing change?: