Skip to content

Commit f74b21a

Browse files
committed
address comments
Signed-off-by: Arko Dasgupta <[email protected]>
1 parent 27db1ea commit f74b21a

File tree

1 file changed

+30
-35
lines changed

1 file changed

+30
-35
lines changed

geps/gep-91/index.md

Lines changed: 30 additions & 35 deletions
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11
# GEP-91: Client Certificate Validation for TLS terminating at the Gateway Listener
22

33
* Issue: [#91](https://github.com/kubernetes-sigs/gateway-api/issues/91)
4-
* Status: Implementable
4+
* Status: Implementable
55

66
(See definitions in [GEP Status][/contributing/gep#status].)
77

@@ -11,10 +11,11 @@ This GEP proposes a way to validate the TLS certificate presented by the downstr
1111
(Gateway Listener in this case) during a [TLS Handshake Protocol][].
1212

1313
## Goals
14-
- Define an API field to specify the CA Certificate within the Gateway Listener configuration that can be used as a trust anchor to validate the certificates presented by the client. This use case has been been highlighted in the [Gateway API TLS Use Cases][] document under point 7.
14+
15+
* Define an API field to specify the CA Certificate within the Gateway Listener configuration that can be used as a trust anchor to validate the certificates presented by the client. This use case has been highlighted in the [TLS Configuration GEP][] under segment 1 and in the [Gateway API TLS Use Cases][] document under point 7.
1516

1617
## Non-Goals
17-
- Define other fields that can be used to verify the client certificate such as the Certificate Hash.
18+
* Define other fields that can be used to verify the client certificate such as the Certificate Hash.
1819

1920
## Existing support in Implementations
2021

@@ -30,37 +31,36 @@ This table highlights the support. Please feel free to add any missing implement
3031
| Istio | [Gateway.Spec.Servers.TLS.Mode](https://istio.io/latest/docs/tasks/traffic-management/ingress/secure-ingress/#configure-a-mutual-tls-ingress-gateway) |
3132
| Kong | [mTLS Plugin](https://docs.konghq.com/hub/kong-inc/mtls-auth/) |
3233
| Traefik | [TLSOption.Spec.ClientAuth](https://doc.traefik.io/traefik/https/tls/#client-authentication-mtls) |
34+
| NGINX Ingress Controller | [ingressMTLS](https://docs.nginx.com/nginx-ingress-controller/configuration/policy-resource/#ingressmtls) |
3335

3436
### API
3537

36-
* Introduce a `Client` field of type `TLSClientContext` within [GatewayTLSConfig][] to hold TLS configuration specific to the client.
37-
* Introduce a `Validation` field of type `TLSValidationContext` within the `Client` field that can be used to validate the peer with which the TLS connection is being made.
38-
to the Gateway.
39-
* Introduce a `caCertificateRefs` field within `ValidationContext` that can be used to specify a list of CA Certificates that
40-
can be used as a trust anchor to validate the certificates presented by the client.
41-
* This new field is mutually exclusive with the [BackendTLSPolicy][] configuation which is used to validate the TLS certificate presented by the peer on the connection between the Gateway and the backend, and this GEP is adding support for validating the TLS certificate presented by the peer on the connection between the Gateway and the downstream client.
42-
* Introduce an optional `subjectAltNames` field within `ClientValidationContext` that can be used to specify one or more alternate names to verify the subject identity in the certificate presented by the client. The maximum number of alternate names that can be specified is implementation defined.
38+
* Introduce a `FrontendValidation` field of type `FrontEndTLSValidationContext` within [GatewayTLSConfig][] that can be used to validate the peer(frontend) with which the TLS connection is being made.
39+
* Introduce a `caCertificateRefs` field within `FrontEndTLSValidationContext` that can be used to specify a list of CA Certificates that can be used as a trust anchor to validate the certificates presented by the client.
40+
* This new field is mutually exclusive with the [BackendTLSPolicy][] configuation which is used to validate the TLS certificate presented by the peer on the connection between the Gateway and the backend, and this GEP is adding support for validating the TLS certificate presented by the peer on the connection between the Gateway and the frontend (downstream client).
4341

4442
#### GO
4543

4644
```go
47-
// TLSClientContext holds configuration specific to the client initiating the TLS connection.
48-
type TLSClientContext struct {
49-
// Validation holds configuration around validating the client initiating the TLS connection.
50-
//
51-
// +optional
52-
Validation *TLSValidationContext `json:"validation,omitempty"`
53-
}
5445

46+
type GatewayTLSConfig struct {
47+
......
48+
// FrontendValidation holds configuration for validating the frontend (client).
49+
// Setting this field will require clients to send a client certificate
50+
// required for validation. In browsers this may result in a dialog appearing
51+
// that requests a user to specify the client certificate.
52+
// The maximum depth of a certificate chain accepted in verification is Implementation specific.
53+
FrontendValidation *FrontEndTLSValidationContext `json:"frontEndValidation,omitempty"`
54+
}
5555

56-
// TLSValidationContext holds configuration that can be used to validate the peer in the TLS connection
57-
type TLSValidationContext struct {
56+
// FrontEndTLSValidationContext holds configuration that can be used to validate the frontend in the TLS connection
57+
type FrontEndTLSValidationContext struct {
5858
// CACertificateRefs contains one or more references to
5959
// Kubernetes objects that contain TLS certificates of
6060
// the Certificate Authorities that can be used
6161
// as a trust anchor to validate the certificates presented by the client.
6262
//
63-
// A single CA certificate reference to a Kubernetes ConfigMap or Secret kind
63+
// A single CA certificate reference to a Kubernetes ConfigMap
6464
// has "Core" support.
6565
// Implementations MAY choose to support attaching multiple CA certificates to
6666
// a Listener, but this behavior is implementation-specific.
@@ -80,14 +80,6 @@ type TLSValidationContext struct {
8080
// +kubebuilder:validation:MaxItems=8
8181
// +kubebuilder:validation:MinItems=1
8282
CACertificateRefs []SecretObjectReference `json:"caCertificateRefs,omitempty"`
83-
// SubjectAltNames contains one or more alternate names to verify
84-
// the subject identity in the certificate presented by the client.
85-
//
86-
// Support: Core
87-
//
88-
// +optional
89-
// +kubebuilder:validation:MinItems=1
90-
SubjectAltNames []string `json:"subjectAltNames,omitempty"`
9183
}
9284

9385
```
@@ -111,25 +103,28 @@ spec:
111103
- kind: Secret
112104
group: ""
113105
name: foo-example-com-cert
114-
client:
115-
validation:
116-
caCertificateRefs:
117-
- kind: ConfigMap
118-
group: ""
119-
name: foo-example-com-ca-cert
106+
frontEndValidation:
107+
caCertificateRefs:
108+
- kind: ConfigMap
109+
group: ""
110+
name: foo-example-com-ca-cert
120111
```
121112
122113
## Deferred
123114
124115
This section highlights use cases that may be covered in a future iteration of this GEP
125116
126117
* Using system CA certificates as the trust anchor to validate the certificates presented by the client.
127-
* Supporting a permissive TLS mode where untrusted clients are allowed in, useful for debugging and migrating to strict TLS.
118+
* Supporting a mode where validating client certficates is optional, useful for debugging and migrating to strict TLS.
119+
* Supporting an optional `subjectAltNames` field within `ClientValidationContext` that can be used to specify one or more alternate names to verify the subject identity in the certificate presented by the client. This field falls under authorization and will be revisited when authorization is tackled as a whole in the project.
120+
* Specifying the verification depth in the client certificates chain
121+
128122

129123
## References
130124

131125
[TLS Handshake Protocol]: https://www.rfc-editor.org/rfc/rfc5246#section-7.4
132126
[Certificate Path Validation]: https://www.rfc-editor.org/rfc/rfc5280#section-6
133127
[GatewayTLSConfig]: https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1.GatewayTLSConfig
134128
[BackendTLSPolicy]: https://gateway-api.sigs.k8s.io/api-types/backendtlspolicy/
129+
[TLS Configuration GEP]: https://gateway-api.sigs.k8s.io/geps/gep-2907/
135130
[Gateway API TLS Use Cases]: https://docs.google.com/document/d/17sctu2uMJtHmJTGtBi_awGB0YzoCLodtR6rUNmKMCs8/edit?pli=1#heading=h.cxuq8vo8pcxm

0 commit comments

Comments
 (0)