You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
***Passthrough**: The Gateway forwards encrypted traffic directly to the backend from the entity originating the connection (called later a client). The TLS connection is established between the client and the backend; the Gateway does not participate in the TLS handshake.
45
36
46
-
#### C. BackendTLSPolicy
47
-
This policy allows us to attach unique TLS configuration per Backend. Depending
48
-
on the organization, this policy may be owned by the application owner or the
49
-
cluster operator. Note that this configuration will be used by all Gateways
50
-
(potentially from different implementations) that are connecting to the backend.
37
+
***Terminate**: The Gateway acts as a man-in-the-middle, terminating the client's TLS connection and originating a separate connection to the backend when routing the traffic. Both connections can independently support TLS and mutual TLS due to their distinct TLS configurations. The Gateway's dual role as a client or server affects the placement of TLS settings needed for given connection.
51
38
52
39
### "Frontend" and "Backend"
53
-
A guiding principle in this naming is to use consistent naming for “Downstream”
54
-
(1+2) and “Upstream” (3+4), similar to Envoy. To avoid the confusion with what
55
-
is upstream and downstream, Gateway API will use “Frontend” (1+2) and “Backend”
40
+
A guiding principle in this naming is to use consistent naming for both TLS connections “Downstream” (1+2) and “Upstream” (3+4) handled by the Gateway (similar to Envoy). To avoid the confusion with what is upstream and downstream, Gateway API will use “Frontend” (1+2) and “Backend”
56
41
(3+4).
57
42
58
43
***Frontend:** The entity connecting to a Gateway, typically a client
@@ -73,43 +58,34 @@ flowchart LR
73
58
74
59
The above diagram depicts these four segments as edges in a graph.
75
60
76
-
###TLS mode
61
+
#### Frontend configuration
77
62
78
-
TLS can be configured with two distinct modes:
63
+
In the Frontend TLS connection Gateway acts as a server and presents Server certificate during TLS handshake. Client connects to the Gateway on domain basis and this is desired to configure Server certificates on the Listener.
64
+
In the mutual frontend TLS Gateway needs to verify client certificates with configured CA. It was expected that CA configuration would be also defined on Listener but due to connection coalescing this solution was not secure. We decided to move client certificate validation configuration on the Gateway level and allow for per port overrides.
65
+
66
+
#### Backend configuration
67
+
68
+
In the Backend connection Gateway acts as a client. The nature of the connection (HTTP or HTTPS) is configured on the Service using BackendTLSPolicy. If BackendTLSPolicy is defined for a Service, the Gateway must establish an HTTPS connection with the backend. During the TLS handshake, the backend presents a Server certificate. The Gateway validates this certificate against a CA certificate (and optionally SANs) configured by BackendTLSPolicy.
69
+
For mutual backend TLS, the Gateway's identity must be configured. This identity, a client certificate set on the Gateway object, will be presented by the Gateway. The Gateway uses the same client certificate for all backend connections originating mutual TLS.
79
70
80
-
***Terminate**: the TLS connection is instantiated between the frontend and the
81
-
Gateway. The connection between the Gateway and the backend is left unencrypted
82
-
unless a new TLS connection between the two entities is configured via BackendTLSPolicy.
83
-
***Passthrough**: the TLS connection is instantiated between the frontend and the
84
-
backend. The traffic flows through the Gateway encrypted, and the Gateway is not
85
-
able to decrypt or inspect the encrypted portions of the TLS stream.
86
71
87
72
## Proposed Segments
88
-
Note that this does not represent any form of commitment that any of these
89
-
fields or concepts will exist within Gateway API. If or when they do, we propose
90
-
the following naming structure:
91
73
92
-
### 1. Validate Client Certificate provided by Frontend
74
+
75
+
### 1. Gateway level configuration
76
+
77
+
Gateway-level configurations are required for both Frontend and Backend connections. We propose a top-level GatewayTLSConfig that is divided into independent Backend and Frontend configurations.
Use FrontendValidation to leave room for concepts like trust anchors and trust
100
-
domains. Anything not strictly tied to validation would belong to Listener.TLS
101
-
which is now reserved exclusively for “Frontend” TLS configuration (1+2).
102
-
103
-
#### Why Not Frontend.Validation?
104
-
Part of the idea behind this GEP is that Listener.TLS is really entirely focused
105
-
on 1+2 - the bits of TLS between frontend and Gateway. That means that if we
106
-
were to add any additional TLS configuration in the Listener.TLS struct, it
107
-
would tied to that limited scope, and thus we don't really need a separate
108
-
Frontend struct.
85
+
From the security point of view both TLS configurations require a Gateway level field. The configurations are independent and can coexist.
109
86
110
-
One could make an argument that Listener.TLS.Validation should be the field name
111
-
here to avoid any ambiguity, but in this specific context, we think that it's
112
-
probably helpful to specifically spell out frontend.
87
+
#### Why Not Listener.Frontend?
88
+
Due to connection coalescing, the client certificate validation for the frontend was moved to a Gateway level field to address security concerns. [GEP-91 Update PR](https://github.com/kubernetes-sigs/gateway-api/pull/3942)
113
89
114
90
#### Why Not FrontendTLSPolicy?
115
91
It could be reasonable to try to mirror BackendTLSPolicy for Frontend TLS. As we
@@ -129,7 +105,7 @@ We don't think either of those reasons really apply to frontend TLS. Instead,
129
105
frontend TLS could theoretically be configured either for an entire Gateway, or
130
106
a specific Gateway listener. Given that many implementations already support
131
107
distinguishing this config per SNI, it seems to make sense to start with
132
-
listener level attachment. We think that the persona that would be responsible
108
+
Listener level attachment. We think that the persona that would be responsible
133
109
for a Gateway is not sufficiently different than the persona that would be
134
110
responsible for frontend TLS, so the current proposal is likely the best option
135
111
available to us.
@@ -145,17 +121,30 @@ This is already finalized in the API and so we're stuck with this name. In
145
121
hindsight a name that was more clearly tied to frontend TLS would have been
146
122
ideal here.
147
123
148
-
### 3. Configure Client Certificate that Gateway should use to connect to Backend
124
+
### 3. Configure Client Certificate Validation for Frontend
125
+
126
+
Client certificate validation will reside at the Gateway level. This configuration will be
127
+
either applied globally to all Listeners in the Gateway or can be overridden on a per-port basis.
149
128
150
129
| Proposed Placement | Name | Status |
151
130
|-|-|-|
152
-
| Gateway |`Gateway.Spec.BackendTLS.ClientCertificateRef`| Not Proposed |
153
-
|BackendTLSPolicy|`BackendTLSPolicy.Spec.ClientCertificateRef`| Not Proposed |
It's not yet obvious which of the above options are preferable, but a case could
157
-
be made for either or both. If we add a `BackendTLS` struct to Gateway it would
158
-
leave room for concepts like TLS version, ALPN, cipher suites, etc.
135
+
Gateway level configuration for client certificate validation was chosen due to security issue.
136
+
137
+
#### Why per port override
138
+
HTTPS connection can be reused between multiple Listeners sharing the same port. This might lead to bypassing client certificate validation configuration for a given Listener becasue new TLS handshake will not be triggered for different hostname.
139
+
140
+
### 4. Configure Client Certificate that Gateway should use to connect to Backend
0 commit comments