From c064cf955574a16f5c02516b95264b38b5b75442 Mon Sep 17 00:00:00 2001 From: Arko Dasgupta Date: Mon, 7 Aug 2023 14:30:04 -0700 Subject: [PATCH 01/21] Adds API to GEP-91: Client Certificate Validation Signed-off-by: Arko Dasgupta --- geps/gep-91/index.md | 62 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 62 insertions(+) diff --git a/geps/gep-91/index.md b/geps/gep-91/index.md index 599a75a25e..18167e8b27 100644 --- a/geps/gep-91/index.md +++ b/geps/gep-91/index.md @@ -16,7 +16,69 @@ This GEP proposes a way to validate the TLS certificate presented by the downstr ## Non-Goals - Define other fields that can be used to verify the client certificate such as the Certificate Hash or Subject Alt Name. +### API + +* Introduce a `clientValidation` field with [Gateway.Tls][] that can be used to validate the client intiating the TLS connection +to the Gateway +* Introduce a `caCerficateRefs` field within `clientValidation` that can be used to specify a list of CA Certificates that +can be used as a trusted anchor to validate the certificates presented by the client + +#### GO + +```go +// ClientValidationContext holds configuration that can be used to validate the client intiating the TLS connection +// to the Gateway. +// By default, no client specific configuration is validated. +type ClientValidationContext struct { + // CACertificateRefs contains one or more references to + // Kubernetes objects that contain TLS certificates of + // the Certificate Authorities that can be used to + // as a trusted anchor to validate the certificates presented by the client. + // + // A single CACertificateRef to a Kubernetes ConfigMap with a key called `ca.crt` + // has "Core" support. + // Implementations MAY choose to support attaching multiple certificates to + // a Listener, but this behavior is implementation-specific. + // + // References to a resource in different namespace are invalid. + // When invalid, "ResolvedRefs" condition MUST be set to False for this listener with the + // "RefNotPermitted" reason. + // + // +kubebuilder:validation:MaxItems=64 + // +optional + CACertificateRefs []LocalObjectReference `json:”caCertificateRefs,omitempty”` +} + +``` + +#### YAML + +```yaml +apiVersion: gateway.networking.k8s.io/v1beta1 +kind: Gateway +metadata: + name: mtls-basic +spec: + gatewayClassName: acme-lb + listeners: + - name: foo-https + protocol: HTTPS + port: 443 + hostname: foo.example.com + tls: + certificateRefs: + - kind: Secret + group: "" + name: foo-example-com-cert + clientValidation: + caCertificateRefs: + - kind: ConfigMap + group: "" + name: foo-example-com-ca-cert +``` + ## References [TLS Handshake Protocol]: https://www.rfc-editor.org/rfc/rfc5246#section-7.4 [Certificate Path Validation]: https://www.rfc-editor.org/rfc/rfc5280#section-6 +[Gateway.TLS]: https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1beta1.GatewayTLSConfig From 1ed3558928f9b69704498bf10886500b4dabfa51 Mon Sep 17 00:00:00 2001 From: Arko Dasgupta Date: Wed, 9 Aug 2023 15:39:36 -0700 Subject: [PATCH 02/21] fix spaces & object ref Signed-off-by: Arko Dasgupta --- geps/gep-91/index.md | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/geps/gep-91/index.md b/geps/gep-91/index.md index 18167e8b27..1559ea46e4 100644 --- a/geps/gep-91/index.md +++ b/geps/gep-91/index.md @@ -35,18 +35,20 @@ type ClientValidationContext struct { // the Certificate Authorities that can be used to // as a trusted anchor to validate the certificates presented by the client. // - // A single CACertificateRef to a Kubernetes ConfigMap with a key called `ca.crt` + // A single CACertificateRef to a Kubernetes ConfigMap with a key called `ca.crt` // has "Core" support. - // Implementations MAY choose to support attaching multiple certificates to - // a Listener, but this behavior is implementation-specific. - // - // References to a resource in different namespace are invalid. - // When invalid, "ResolvedRefs" condition MUST be set to False for this listener with the - // "RefNotPermitted" reason. + // Implementations MAY choose to support attaching multiple certificates to + // a Listener, but this behavior is implementation-specific. + // + // References to a resource in different namespace are invalid UNLESS there + // is a ReferenceGrant in the target namespace that allows the certificate + // to be attached. If a ReferenceGrant does not allow this reference, the + // "ResolvedRefs" condition MUST be set to False for this listener with the + // "RefNotPermitted" reason. // // +kubebuilder:validation:MaxItems=64 // +optional - CACertificateRefs []LocalObjectReference `json:”caCertificateRefs,omitempty”` + CACertificateRefs []corev1.ObjectReference `json:”caCertificateRefs,omitempty”` } ``` From 94a4a0d0323b4a4ecaf99293ccce5e5955e397af Mon Sep 17 00:00:00 2001 From: Arko Dasgupta Date: Mon, 14 Aug 2023 16:42:41 -0700 Subject: [PATCH 03/21] fix indentation Signed-off-by: Arko Dasgupta --- geps/gep-91/index.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/geps/gep-91/index.md b/geps/gep-91/index.md index 1559ea46e4..cde60fa673 100644 --- a/geps/gep-91/index.md +++ b/geps/gep-91/index.md @@ -72,11 +72,11 @@ spec: - kind: Secret group: "" name: foo-example-com-cert - clientValidation: - caCertificateRefs: - - kind: ConfigMap - group: "" - name: foo-example-com-ca-cert + clientValidation: + caCertificateRefs: + - kind: ConfigMap + group: "" + name: foo-example-com-ca-cert ``` ## References From 4b7c8286582d68e36a52f0987b89d9c1035e6097 Mon Sep 17 00:00:00 2001 From: Arko Dasgupta Date: Thu, 17 Aug 2023 12:40:05 -0700 Subject: [PATCH 04/21] more gep to Implementable Signed-off-by: Arko Dasgupta --- geps/gep-91/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/geps/gep-91/index.md b/geps/gep-91/index.md index cde60fa673..55611247f3 100644 --- a/geps/gep-91/index.md +++ b/geps/gep-91/index.md @@ -1,7 +1,7 @@ # GEP-91: Client Certificate Validation for TLS terminating at the Gateway Listener * Issue: [#91](https://github.com/kubernetes-sigs/gateway-api/issues/91) -* Status: Provisional +* Status: Implementable (See definitions in [GEP Status][/contributing/gep#status].) From fd9bfcfec72f0df5640d2262f08ca88c2794cc4e Mon Sep 17 00:00:00 2001 From: Arko Dasgupta Date: Thu, 28 Dec 2023 14:48:49 -0800 Subject: [PATCH 05/21] address comments Signed-off-by: Arko Dasgupta --- geps/gep-91/index.md | 31 ++++++++++++++++++------------- 1 file changed, 18 insertions(+), 13 deletions(-) diff --git a/geps/gep-91/index.md b/geps/gep-91/index.md index 55611247f3..26e16d48c0 100644 --- a/geps/gep-91/index.md +++ b/geps/gep-91/index.md @@ -8,20 +8,20 @@ ## TLDR This GEP proposes a way to validate the TLS certificate presented by the downstream client to the server -(Gateway Listener in this case) during a [TLS Handshake Protocol][], also commonly referred to as mutual TLS (mTLS). +(Gateway Listener in this case) during a [TLS Handshake Protocol][]. ## Goals -- Define an API field to specify the CA Certificate within the Gateway Listener configuration that can be used as a trusted anchor to validate the certificates presented by the client. +- 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. ## Non-Goals - Define other fields that can be used to verify the client certificate such as the Certificate Hash or Subject Alt Name. ### API -* Introduce a `clientValidation` field with [Gateway.Tls][] that can be used to validate the client intiating the TLS connection -to the Gateway -* Introduce a `caCerficateRefs` field within `clientValidation` that can be used to specify a list of CA Certificates that -can be used as a trusted anchor to validate the certificates presented by the client +* Introduce a `clientValidation` field of type `ClientValidationContext` within [GatewayTLSConfig][] that can be used to validate the client initiating the TLS connection +to the Gateway. +* Introduce a `caCertificateRefs` field within `ClientValidationContext` 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. #### GO @@ -33,20 +33,25 @@ type ClientValidationContext struct { // CACertificateRefs contains one or more references to // Kubernetes objects that contain TLS certificates of // the Certificate Authorities that can be used to - // as a trusted anchor to validate the certificates presented by the client. + // as a trust anchor to validate the certificates presented by the client. // - // A single CACertificateRef to a Kubernetes ConfigMap with a key called `ca.crt` - // has "Core" support. - // Implementations MAY choose to support attaching multiple certificates to + // A single CACertRef to a Kubernetes ConfigMap kind has "Core" support. + // Implementations MAY choose to support attaching multiple CA certificates to // a Listener, but this behavior is implementation-specific. // + // Support: Core - An optional single reference to a Kubernetes ConfigMap, + // with the CA certificate in a key named `ca.crt`. + // + // Support: Implementation-specific (More than one reference, or other kinds + // of resources). + // // References to a resource in different namespace are invalid UNLESS there // is a ReferenceGrant in the target namespace that allows the certificate // to be attached. If a ReferenceGrant does not allow this reference, the // "ResolvedRefs" condition MUST be set to False for this listener with the // "RefNotPermitted" reason. // - // +kubebuilder:validation:MaxItems=64 + // +kubebuilder:validation:MaxItems=8 // +optional CACertificateRefs []corev1.ObjectReference `json:”caCertificateRefs,omitempty”` } @@ -59,7 +64,7 @@ type ClientValidationContext struct { apiVersion: gateway.networking.k8s.io/v1beta1 kind: Gateway metadata: - name: mtls-basic + name: client-validation-basic spec: gatewayClassName: acme-lb listeners: @@ -83,4 +88,4 @@ spec: [TLS Handshake Protocol]: https://www.rfc-editor.org/rfc/rfc5246#section-7.4 [Certificate Path Validation]: https://www.rfc-editor.org/rfc/rfc5280#section-6 -[Gateway.TLS]: https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1beta1.GatewayTLSConfig +[GatewayTLSConfig]: https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1beta1.GatewayTLSConfig From 04b04de0afacf18ff8aeac41937cf4e1d13bc5e0 Mon Sep 17 00:00:00 2001 From: Arko Dasgupta Date: Tue, 2 Jan 2024 15:30:20 -0800 Subject: [PATCH 06/21] add link to gateway tls use cases Signed-off-by: Arko Dasgupta --- geps/gep-91/index.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/geps/gep-91/index.md b/geps/gep-91/index.md index 26e16d48c0..c5d6106d12 100644 --- a/geps/gep-91/index.md +++ b/geps/gep-91/index.md @@ -11,7 +11,7 @@ This GEP proposes a way to validate the TLS certificate presented by the downstr (Gateway Listener in this case) during a [TLS Handshake Protocol][]. ## Goals -- 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. +- 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. ## Non-Goals - Define other fields that can be used to verify the client certificate such as the Certificate Hash or Subject Alt Name. @@ -89,3 +89,4 @@ spec: [TLS Handshake Protocol]: https://www.rfc-editor.org/rfc/rfc5246#section-7.4 [Certificate Path Validation]: https://www.rfc-editor.org/rfc/rfc5280#section-6 [GatewayTLSConfig]: https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1beta1.GatewayTLSConfig +[Gateway API TLS Use Cases]: https://docs.google.com/document/d/17sctu2uMJtHmJTGtBi_awGB0YzoCLodtR6rUNmKMCs8/edit?pli=1#heading=h.cxuq8vo8pcxm From 11ca0d4dc8942ef8c2ffa8fd4bb4434ea4184cd8 Mon Sep 17 00:00:00 2001 From: Arko Dasgupta Date: Thu, 1 Feb 2024 16:40:15 -0800 Subject: [PATCH 07/21] address more comments Signed-off-by: Arko Dasgupta --- geps/gep-91/index.md | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/geps/gep-91/index.md b/geps/gep-91/index.md index c5d6106d12..244fef7b74 100644 --- a/geps/gep-91/index.md +++ b/geps/gep-91/index.md @@ -22,6 +22,9 @@ This GEP proposes a way to validate the TLS certificate presented by the downstr to the Gateway. * Introduce a `caCertificateRefs` field within `ClientValidationContext` 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. +* Add CEL validation to ensure that `caCertificateRefs` cannot be empty. This validation will be removed once more fields are added +into `clientValidation`. +* 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. #### GO @@ -32,10 +35,10 @@ can be used as a trust anchor to validate the certificates presented by the clie type ClientValidationContext struct { // CACertificateRefs contains one or more references to // Kubernetes objects that contain TLS certificates of - // the Certificate Authorities that can be used to + // the Certificate Authorities that can be used // as a trust anchor to validate the certificates presented by the client. // - // A single CACertRef to a Kubernetes ConfigMap kind has "Core" support. + // A single CA certificate reference to a Kubernetes ConfigMap kind has "Core" support. // Implementations MAY choose to support attaching multiple CA certificates to // a Listener, but this behavior is implementation-specific. // @@ -45,7 +48,7 @@ type ClientValidationContext struct { // Support: Implementation-specific (More than one reference, or other kinds // of resources). // - // References to a resource in different namespace are invalid UNLESS there + // References to a resource in a different namespace are invalid UNLESS there // is a ReferenceGrant in the target namespace that allows the certificate // to be attached. If a ReferenceGrant does not allow this reference, the // "ResolvedRefs" condition MUST be set to False for this listener with the @@ -84,9 +87,16 @@ spec: name: foo-example-com-ca-cert ``` +## Deferred + +This section highlights use cases that may be covered in a future iteration of this GEP + +* Using system CA certificates as the trust anchor to validate the certificates presented by the client. + ## References [TLS Handshake Protocol]: https://www.rfc-editor.org/rfc/rfc5246#section-7.4 [Certificate Path Validation]: https://www.rfc-editor.org/rfc/rfc5280#section-6 -[GatewayTLSConfig]: https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1beta1.GatewayTLSConfig +[GatewayTLSConfig]: https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1.GatewayTLSConfig +[BackendTLSPolicy]: https://gateway-api.sigs.k8s.io/api-types/backendtlspolicy/ [Gateway API TLS Use Cases]: https://docs.google.com/document/d/17sctu2uMJtHmJTGtBi_awGB0YzoCLodtR6rUNmKMCs8/edit?pli=1#heading=h.cxuq8vo8pcxm From 93bf4e0bd9c9c429077be3a70e2730348c5c6468 Mon Sep 17 00:00:00 2001 From: Arko Dasgupta Date: Thu, 1 Feb 2024 17:39:31 -0800 Subject: [PATCH 08/21] comparison table Signed-off-by: Arko Dasgupta --- geps/gep-91/index.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/geps/gep-91/index.md b/geps/gep-91/index.md index 244fef7b74..3decb63e1b 100644 --- a/geps/gep-91/index.md +++ b/geps/gep-91/index.md @@ -10,6 +10,21 @@ This GEP proposes a way to validate the TLS certificate presented by the downstream client to the server (Gateway Listener in this case) during a [TLS Handshake Protocol][]. +### Existing support in Implementations + +This feature is widely supported in implementations that support Gateway API. +This table highlights the support. Please feel free to add any missing implementations not mentioned below. + +| Implementation | Support | +|----------------|------------| +| Apache APISIX | [ApisixTls.Client.CASecret](https://apisix.apache.org/docs/ingress-controller/tutorials/mtls/#mutual-authentication) | +| Contour | [HTTPProxy.Spec.VirtualHost.Tls.ClientValidation.CASecret](https://projectcontour.io/docs/v1.17.1/config/tls-termination/) | +| Emissary Ingress| [TlSContext.Spec.Secret](https://www.getambassador.io/docs/emissary/latest/topics/running/tls/mtls) | +| Gloo Edge | [VirtualService.Spec.SSLConfig.SecretRef](https://docs.solo.io/gloo-edge/latest/guides/security/tls/server_tls/#configuring-downstream-mtls-in-a-virtual-service) | +| Istio | [Gateway.Spec.Servers.TLS.Mode](https://istio.io/latest/docs/tasks/traffic-management/ingress/secure-ingress/#configure-a-mutual-tls-ingress-gateway) | +| Kong | [mTLS Plugin](https://docs.konghq.com/hub/kong-inc/mtls-auth/) | +| Traefik | [TLSOption.Spec.ClientAuth](https://doc.traefik.io/traefik/https/tls/#client-authentication-mtls) | + ## Goals - 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. From b0625b65229d555afbcb8c8400010990ea4de1f0 Mon Sep 17 00:00:00 2001 From: Arko Dasgupta Date: Thu, 1 Feb 2024 17:41:13 -0800 Subject: [PATCH 09/21] move Signed-off-by: Arko Dasgupta --- geps/gep-91/index.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/geps/gep-91/index.md b/geps/gep-91/index.md index 3decb63e1b..8ad3816f91 100644 --- a/geps/gep-91/index.md +++ b/geps/gep-91/index.md @@ -10,7 +10,13 @@ This GEP proposes a way to validate the TLS certificate presented by the downstream client to the server (Gateway Listener in this case) during a [TLS Handshake Protocol][]. -### Existing support in Implementations +## Goals +- 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. + +## Non-Goals +- Define other fields that can be used to verify the client certificate such as the Certificate Hash or Subject Alt Name. + +## Existing support in Implementations This feature is widely supported in implementations that support Gateway API. This table highlights the support. Please feel free to add any missing implementations not mentioned below. @@ -25,12 +31,6 @@ This table highlights the support. Please feel free to add any missing implement | Kong | [mTLS Plugin](https://docs.konghq.com/hub/kong-inc/mtls-auth/) | | Traefik | [TLSOption.Spec.ClientAuth](https://doc.traefik.io/traefik/https/tls/#client-authentication-mtls) | -## Goals -- 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. - -## Non-Goals -- Define other fields that can be used to verify the client certificate such as the Certificate Hash or Subject Alt Name. - ### API * Introduce a `clientValidation` field of type `ClientValidationContext` within [GatewayTLSConfig][] that can be used to validate the client initiating the TLS connection From 3b82df55c5049613149ac1867d1144248108719a Mon Sep 17 00:00:00 2001 From: Arko Dasgupta Date: Fri, 2 Feb 2024 09:13:31 -0800 Subject: [PATCH 10/21] use SecretObjectReference Signed-off-by: Arko Dasgupta --- geps/gep-91/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/geps/gep-91/index.md b/geps/gep-91/index.md index 8ad3816f91..6c55196bce 100644 --- a/geps/gep-91/index.md +++ b/geps/gep-91/index.md @@ -71,7 +71,7 @@ type ClientValidationContext struct { // // +kubebuilder:validation:MaxItems=8 // +optional - CACertificateRefs []corev1.ObjectReference `json:”caCertificateRefs,omitempty”` + CACertificateRefs []SecretObjectReference `json:”caCertificateRefs,omitempty”` } ``` From b533b399564a980dcd1b7ffd040b7328d78a325e Mon Sep 17 00:00:00 2001 From: Arko Dasgupta Date: Fri, 2 Feb 2024 11:16:35 -0800 Subject: [PATCH 11/21] core support for secret Signed-off-by: Arko Dasgupta --- geps/gep-91/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/geps/gep-91/index.md b/geps/gep-91/index.md index 6c55196bce..764733d7b5 100644 --- a/geps/gep-91/index.md +++ b/geps/gep-91/index.md @@ -57,7 +57,7 @@ type ClientValidationContext struct { // Implementations MAY choose to support attaching multiple CA certificates to // a Listener, but this behavior is implementation-specific. // - // Support: Core - An optional single reference to a Kubernetes ConfigMap, + // Support: Core - An optional single reference to a Kubernetes Secret and ConfigMap, // with the CA certificate in a key named `ca.crt`. // // Support: Implementation-specific (More than one reference, or other kinds From 1a444dafa4f1d9677cefcb153785ade44c01e83b Mon Sep 17 00:00:00 2001 From: Arko Dasgupta Date: Tue, 6 Feb 2024 08:34:30 -0800 Subject: [PATCH 12/21] add SAN support Signed-off-by: Arko Dasgupta --- geps/gep-91/index.md | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/geps/gep-91/index.md b/geps/gep-91/index.md index 764733d7b5..764aa4fafc 100644 --- a/geps/gep-91/index.md +++ b/geps/gep-91/index.md @@ -14,7 +14,7 @@ This GEP proposes a way to validate the TLS certificate presented by the downstr - 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. ## Non-Goals -- Define other fields that can be used to verify the client certificate such as the Certificate Hash or Subject Alt Name. +- Define other fields that can be used to verify the client certificate such as the Certificate Hash. ## Existing support in Implementations @@ -37,8 +37,6 @@ This table highlights the support. Please feel free to add any missing implement to the Gateway. * Introduce a `caCertificateRefs` field within `ClientValidationContext` 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. -* Add CEL validation to ensure that `caCertificateRefs` cannot be empty. This validation will be removed once more fields are added -into `clientValidation`. * 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. #### GO @@ -70,8 +68,15 @@ type ClientValidationContext struct { // "RefNotPermitted" reason. // // +kubebuilder:validation:MaxItems=8 - // +optional + // +kubebuilder:validation:MinItems=1 CACertificateRefs []SecretObjectReference `json:”caCertificateRefs,omitempty”` + // SubjectAltNames contains one or more alternate names to verify + // the subject identity in the certificate presented by the client. + // + // Support: Core + // + // +optional + SubjectAltNames []string `json:"subjectAltNames,omitempty"` } ``` From 74fb42c5927fc9b6845d8362d25e1af52cf96755 Mon Sep 17 00:00:00 2001 From: Arko Dasgupta Date: Thu, 8 Feb 2024 15:23:41 -0800 Subject: [PATCH 13/21] fix doc string Signed-off-by: Arko Dasgupta --- geps/gep-91/index.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/geps/gep-91/index.md b/geps/gep-91/index.md index 764aa4fafc..54da50fa7a 100644 --- a/geps/gep-91/index.md +++ b/geps/gep-91/index.md @@ -51,7 +51,8 @@ type ClientValidationContext struct { // the Certificate Authorities that can be used // as a trust anchor to validate the certificates presented by the client. // - // A single CA certificate reference to a Kubernetes ConfigMap kind has "Core" support. + // A single CA certificate reference to a Kubernetes ConfigMap or Secret kind + // has "Core" support. // Implementations MAY choose to support attaching multiple CA certificates to // a Listener, but this behavior is implementation-specific. // From bcf8d68959779884f4be220e5022cd9802663e01 Mon Sep 17 00:00:00 2001 From: Arko Dasgupta Date: Thu, 8 Feb 2024 15:54:54 -0800 Subject: [PATCH 14/21] address comment Signed-off-by: Arko Dasgupta --- geps/gep-91/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/geps/gep-91/index.md b/geps/gep-91/index.md index 54da50fa7a..42a966b0b2 100644 --- a/geps/gep-91/index.md +++ b/geps/gep-91/index.md @@ -56,8 +56,8 @@ type ClientValidationContext struct { // Implementations MAY choose to support attaching multiple CA certificates to // a Listener, but this behavior is implementation-specific. // - // Support: Core - An optional single reference to a Kubernetes Secret and ConfigMap, - // with the CA certificate in a key named `ca.crt`. + // Support: Core - An optional single reference to a single Kubernetes Secret + // and to a single Kubernetes ConfigMap with the CA certificate in a key named `ca.crt`. // // Support: Implementation-specific (More than one reference, or other kinds // of resources). From 48ac66946b4a3288a20b0937c133c966f9385f31 Mon Sep 17 00:00:00 2001 From: Arko Dasgupta Date: Mon, 12 Feb 2024 11:57:52 -0800 Subject: [PATCH 15/21] add min list limit for SAN Signed-off-by: Arko Dasgupta --- geps/gep-91/index.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/geps/gep-91/index.md b/geps/gep-91/index.md index 42a966b0b2..c20c3e4014 100644 --- a/geps/gep-91/index.md +++ b/geps/gep-91/index.md @@ -38,6 +38,7 @@ to the Gateway. * Introduce a `caCertificateRefs` field within `ClientValidationContext` 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. * 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. +* 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. #### GO @@ -77,6 +78,7 @@ type ClientValidationContext struct { // Support: Core // // +optional + // +kubebuilder:validation:MinItems=1 SubjectAltNames []string `json:"subjectAltNames,omitempty"` } From 27db1ea630161cac1f6f31294889fd428a7f330c Mon Sep 17 00:00:00 2001 From: Arko Dasgupta Date: Mon, 11 Mar 2024 14:13:53 -0700 Subject: [PATCH 16/21] top level `client` field with `validation` inside Signed-off-by: Arko Dasgupta --- geps/gep-91/index.md | 34 ++++++++++++++++++++++------------ 1 file changed, 22 insertions(+), 12 deletions(-) diff --git a/geps/gep-91/index.md b/geps/gep-91/index.md index c20c3e4014..9f924cbd19 100644 --- a/geps/gep-91/index.md +++ b/geps/gep-91/index.md @@ -33,9 +33,10 @@ This table highlights the support. Please feel free to add any missing implement ### API -* Introduce a `clientValidation` field of type `ClientValidationContext` within [GatewayTLSConfig][] that can be used to validate the client initiating the TLS connection +* Introduce a `Client` field of type `TLSClientContext` within [GatewayTLSConfig][] to hold TLS configuration specific to the client. +* 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. to the Gateway. -* Introduce a `caCertificateRefs` field within `ClientValidationContext` that can be used to specify a list of CA Certificates that +* Introduce a `caCertificateRefs` field within `ValidationContext` 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. * 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. * 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. @@ -43,10 +44,17 @@ can be used as a trust anchor to validate the certificates presented by the clie #### GO ```go -// ClientValidationContext holds configuration that can be used to validate the client intiating the TLS connection -// to the Gateway. -// By default, no client specific configuration is validated. -type ClientValidationContext struct { +// TLSClientContext holds configuration specific to the client initiating the TLS connection. +type TLSClientContext struct { + // Validation holds configuration around validating the client initiating the TLS connection. + // + // +optional + Validation *TLSValidationContext `json:"validation,omitempty"` +} + + +// TLSValidationContext holds configuration that can be used to validate the peer in the TLS connection +type TLSValidationContext struct { // CACertificateRefs contains one or more references to // Kubernetes objects that contain TLS certificates of // the Certificate Authorities that can be used @@ -71,7 +79,7 @@ type ClientValidationContext struct { // // +kubebuilder:validation:MaxItems=8 // +kubebuilder:validation:MinItems=1 - CACertificateRefs []SecretObjectReference `json:”caCertificateRefs,omitempty”` + CACertificateRefs []SecretObjectReference `json:"caCertificateRefs,omitempty"` // SubjectAltNames contains one or more alternate names to verify // the subject identity in the certificate presented by the client. // @@ -103,11 +111,12 @@ spec: - kind: Secret group: "" name: foo-example-com-cert - clientValidation: - caCertificateRefs: - - kind: ConfigMap - group: "" - name: foo-example-com-ca-cert + client: + validation: + caCertificateRefs: + - kind: ConfigMap + group: "" + name: foo-example-com-ca-cert ``` ## Deferred @@ -115,6 +124,7 @@ spec: This section highlights use cases that may be covered in a future iteration of this GEP * Using system CA certificates as the trust anchor to validate the certificates presented by the client. +* Supporting a permissive TLS mode where untrusted clients are allowed in, useful for debugging and migrating to strict TLS. ## References From f74b21a0760e3583cd9c7382518877787be91b92 Mon Sep 17 00:00:00 2001 From: Arko Dasgupta Date: Thu, 4 Apr 2024 21:59:36 -0700 Subject: [PATCH 17/21] address comments Signed-off-by: Arko Dasgupta --- geps/gep-91/index.md | 65 ++++++++++++++++++++------------------------ 1 file changed, 30 insertions(+), 35 deletions(-) diff --git a/geps/gep-91/index.md b/geps/gep-91/index.md index 9f924cbd19..4b816c40d1 100644 --- a/geps/gep-91/index.md +++ b/geps/gep-91/index.md @@ -1,7 +1,7 @@ # GEP-91: Client Certificate Validation for TLS terminating at the Gateway Listener * Issue: [#91](https://github.com/kubernetes-sigs/gateway-api/issues/91) -* Status: Implementable +* Status: Implementable (See definitions in [GEP Status][/contributing/gep#status].) @@ -11,10 +11,11 @@ This GEP proposes a way to validate the TLS certificate presented by the downstr (Gateway Listener in this case) during a [TLS Handshake Protocol][]. ## Goals -- 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. + +* 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. ## Non-Goals -- Define other fields that can be used to verify the client certificate such as the Certificate Hash. +* Define other fields that can be used to verify the client certificate such as the Certificate Hash. ## Existing support in Implementations @@ -30,37 +31,36 @@ This table highlights the support. Please feel free to add any missing implement | Istio | [Gateway.Spec.Servers.TLS.Mode](https://istio.io/latest/docs/tasks/traffic-management/ingress/secure-ingress/#configure-a-mutual-tls-ingress-gateway) | | Kong | [mTLS Plugin](https://docs.konghq.com/hub/kong-inc/mtls-auth/) | | Traefik | [TLSOption.Spec.ClientAuth](https://doc.traefik.io/traefik/https/tls/#client-authentication-mtls) | +| NGINX Ingress Controller | [ingressMTLS](https://docs.nginx.com/nginx-ingress-controller/configuration/policy-resource/#ingressmtls) | ### API -* Introduce a `Client` field of type `TLSClientContext` within [GatewayTLSConfig][] to hold TLS configuration specific to the client. -* 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. -to the Gateway. -* Introduce a `caCertificateRefs` field within `ValidationContext` 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. -* 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. -* 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. +* 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. +* 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. +* 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). #### GO ```go -// TLSClientContext holds configuration specific to the client initiating the TLS connection. -type TLSClientContext struct { - // Validation holds configuration around validating the client initiating the TLS connection. - // - // +optional - Validation *TLSValidationContext `json:"validation,omitempty"` -} +type GatewayTLSConfig struct { +...... + // FrontendValidation holds configuration for validating the frontend (client). + // Setting this field will require clients to send a client certificate + // required for validation. In browsers this may result in a dialog appearing + // that requests a user to specify the client certificate. + // The maximum depth of a certificate chain accepted in verification is Implementation specific. + FrontendValidation *FrontEndTLSValidationContext `json:"frontEndValidation,omitempty"` +} -// TLSValidationContext holds configuration that can be used to validate the peer in the TLS connection -type TLSValidationContext struct { +// FrontEndTLSValidationContext holds configuration that can be used to validate the frontend in the TLS connection +type FrontEndTLSValidationContext struct { // CACertificateRefs contains one or more references to // Kubernetes objects that contain TLS certificates of // the Certificate Authorities that can be used // as a trust anchor to validate the certificates presented by the client. // - // A single CA certificate reference to a Kubernetes ConfigMap or Secret kind + // A single CA certificate reference to a Kubernetes ConfigMap // has "Core" support. // Implementations MAY choose to support attaching multiple CA certificates to // a Listener, but this behavior is implementation-specific. @@ -80,14 +80,6 @@ type TLSValidationContext struct { // +kubebuilder:validation:MaxItems=8 // +kubebuilder:validation:MinItems=1 CACertificateRefs []SecretObjectReference `json:"caCertificateRefs,omitempty"` - // SubjectAltNames contains one or more alternate names to verify - // the subject identity in the certificate presented by the client. - // - // Support: Core - // - // +optional - // +kubebuilder:validation:MinItems=1 - SubjectAltNames []string `json:"subjectAltNames,omitempty"` } ``` @@ -111,12 +103,11 @@ spec: - kind: Secret group: "" name: foo-example-com-cert - client: - validation: - caCertificateRefs: - - kind: ConfigMap - group: "" - name: foo-example-com-ca-cert + frontEndValidation: + caCertificateRefs: + - kind: ConfigMap + group: "" + name: foo-example-com-ca-cert ``` ## Deferred @@ -124,7 +115,10 @@ spec: This section highlights use cases that may be covered in a future iteration of this GEP * Using system CA certificates as the trust anchor to validate the certificates presented by the client. -* Supporting a permissive TLS mode where untrusted clients are allowed in, useful for debugging and migrating to strict TLS. +* Supporting a mode where validating client certficates is optional, useful for debugging and migrating to strict TLS. +* 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. +* Specifying the verification depth in the client certificates chain + ## References @@ -132,4 +126,5 @@ This section highlights use cases that may be covered in a future iteration of t [Certificate Path Validation]: https://www.rfc-editor.org/rfc/rfc5280#section-6 [GatewayTLSConfig]: https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1.GatewayTLSConfig [BackendTLSPolicy]: https://gateway-api.sigs.k8s.io/api-types/backendtlspolicy/ +[TLS Configuration GEP]: https://gateway-api.sigs.k8s.io/geps/gep-2907/ [Gateway API TLS Use Cases]: https://docs.google.com/document/d/17sctu2uMJtHmJTGtBi_awGB0YzoCLodtR6rUNmKMCs8/edit?pli=1#heading=h.cxuq8vo8pcxm From bb9d41935a42004ede3a93ab7ba13d0fef088453 Mon Sep 17 00:00:00 2001 From: Arko Dasgupta Date: Fri, 5 Apr 2024 00:01:47 -0700 Subject: [PATCH 18/21] typos and grammar Signed-off-by: Arko Dasgupta --- geps/gep-91/index.md | 29 +++++++++++++++-------------- 1 file changed, 15 insertions(+), 14 deletions(-) diff --git a/geps/gep-91/index.md b/geps/gep-91/index.md index 4b816c40d1..a4dfe6a1b1 100644 --- a/geps/gep-91/index.md +++ b/geps/gep-91/index.md @@ -7,7 +7,7 @@ ## TLDR -This GEP proposes a way to validate the TLS certificate presented by the downstream client to the server +This GEP proposes a way to validate the TLS certificate presented by the frontend client to the server (Gateway Listener in this case) during a [TLS Handshake Protocol][]. ## Goals @@ -35,26 +35,27 @@ This table highlights the support. Please feel free to add any missing implement ### API -* 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. -* 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. -* 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). +* Introduce a `FrontendValidation` field of type `FrontendTLSValidation` within [GatewayTLSConfig][] that can be used to validate the peer (frontend) with which the TLS connection is being made. +* Introduce a `caCertificateRefs` field within `FrontendTLSValidation` 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. +* This new field is mutually exclusive with the [BackendTLSPolicy][] configuation which is used to validate the TLS certificate presented by the backend peer on the connection between the Gateway and the backend, and this GEP is adding support for validating the TLS certificate presented by the frontend client on the connection between the Gateway and the frontend. Both these configurations can coexist at the same time without affecting one another. #### GO ```go type GatewayTLSConfig struct { -...... - // FrontendValidation holds configuration for validating the frontend (client). + ...... + // FrontendValidation holds configuration information for validating the frontend (client). // Setting this field will require clients to send a client certificate - // required for validation. In browsers this may result in a dialog appearing + // required for validation during the TLS handshake. In browsers this may result in a dialog appearing // that requests a user to specify the client certificate. // The maximum depth of a certificate chain accepted in verification is Implementation specific. - FrontendValidation *FrontEndTLSValidationContext `json:"frontEndValidation,omitempty"` + FrontendValidation *FrontendTLSValidation `json:"frontendValidation,omitempty"` } -// FrontEndTLSValidationContext holds configuration that can be used to validate the frontend in the TLS connection -type FrontEndTLSValidationContext struct { +// FrontendTLSValidation holds configuration information that can be used to validate +// the frontend initiating the TLS connection +type FrontendTLSValidationContext struct { // CACertificateRefs contains one or more references to // Kubernetes objects that contain TLS certificates of // the Certificate Authorities that can be used @@ -103,7 +104,7 @@ spec: - kind: Secret group: "" name: foo-example-com-cert - frontEndValidation: + frontendValidation: caCertificateRefs: - kind: ConfigMap group: "" @@ -114,10 +115,10 @@ spec: This section highlights use cases that may be covered in a future iteration of this GEP -* Using system CA certificates as the trust anchor to validate the certificates presented by the client. +* Using system CA certificates as the trust anchor to validate the certificates presented by the frontend client. * Supporting a mode where validating client certficates is optional, useful for debugging and migrating to strict TLS. -* 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. -* Specifying the verification depth in the client certificates chain +* Supporting an optional `subjectAltNames` field within `FrontendTLSValidation` 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, the initial focus here is on Client Authentication and will be revisited when Authorization is tackled as a whole in the project. +* Specifying the verification depth in the client certificate chain. This is being deferred because the default verification depth differs across implementations. ## References From fabc56b59de7a66ff4279e0f71cc46c08e2527c6 Mon Sep 17 00:00:00 2001 From: Arko Dasgupta Date: Fri, 5 Apr 2024 09:59:31 -0700 Subject: [PATCH 19/21] add ObjectReference Signed-off-by: Arko Dasgupta --- geps/gep-91/index.md | 35 ++++++++++++++++++++++++++++++++++- 1 file changed, 34 insertions(+), 1 deletion(-) diff --git a/geps/gep-91/index.md b/geps/gep-91/index.md index a4dfe6a1b1..47834fcf2c 100644 --- a/geps/gep-91/index.md +++ b/geps/gep-91/index.md @@ -38,10 +38,43 @@ This table highlights the support. Please feel free to add any missing implement * Introduce a `FrontendValidation` field of type `FrontendTLSValidation` within [GatewayTLSConfig][] that can be used to validate the peer (frontend) with which the TLS connection is being made. * Introduce a `caCertificateRefs` field within `FrontendTLSValidation` 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. * This new field is mutually exclusive with the [BackendTLSPolicy][] configuation which is used to validate the TLS certificate presented by the backend peer on the connection between the Gateway and the backend, and this GEP is adding support for validating the TLS certificate presented by the frontend client on the connection between the Gateway and the frontend. Both these configurations can coexist at the same time without affecting one another. +* Also introduce a `ObjectReference` structure that can be used to specify `caCertificateRefs` references. #### GO ```go +// ObjectReference identifies an API object including its namespace. +// +// The API object must be valid in the cluster; the Group and Kind must +// be registered in the cluster for this reference to be valid. +// +// References to objects with invalid Group and Kind are not valid, and must +// be rejected by the implementation, with appropriate Conditions set +// on the containing object. +type ObjectReference struct { + // Group is the group of the referent. For example, "gateway.networking.k8s.io". + // When unspecified or empty string, core API group is inferred. + Group Group `json:"group"` + + // Kind is kind of the referent. For example "ConfigMap" or "Service". + Kind Kind `json:"kind"` + + // Name is the name of the referent. + Name ObjectName `json:"name"` + + // Namespace is the namespace of the referenced object. When unspecified, the local + // namespace is inferred. + // + // Note that when a namespace different than the local namespace is specified, + // a ReferenceGrant object is required in the referent namespace to allow that + // namespace's owner to accept the reference. See the ReferenceGrant + // documentation for details. + // + // Support: Core + // + // +optional + Namespace *Namespace `json:"namespace,omitempty"` +} type GatewayTLSConfig struct { ...... @@ -80,7 +113,7 @@ type FrontendTLSValidationContext struct { // // +kubebuilder:validation:MaxItems=8 // +kubebuilder:validation:MinItems=1 - CACertificateRefs []SecretObjectReference `json:"caCertificateRefs,omitempty"` + CACertificateRefs []ObjectReference `json:"caCertificateRefs,omitempty"` } ``` From ced1c5fca3b5fdaaf7cafd9a5385f843d4dcc069 Mon Sep 17 00:00:00 2001 From: Arko Dasgupta Date: Fri, 5 Apr 2024 19:26:16 -0700 Subject: [PATCH 20/21] rm instance of Secret Signed-off-by: Arko Dasgupta --- geps/gep-91/index.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/geps/gep-91/index.md b/geps/gep-91/index.md index 47834fcf2c..e04f1f75e4 100644 --- a/geps/gep-91/index.md +++ b/geps/gep-91/index.md @@ -88,7 +88,7 @@ type GatewayTLSConfig struct { // FrontendTLSValidation holds configuration information that can be used to validate // the frontend initiating the TLS connection -type FrontendTLSValidationContext struct { +type FrontendTLSValidation struct { // CACertificateRefs contains one or more references to // Kubernetes objects that contain TLS certificates of // the Certificate Authorities that can be used @@ -99,8 +99,8 @@ type FrontendTLSValidationContext struct { // Implementations MAY choose to support attaching multiple CA certificates to // a Listener, but this behavior is implementation-specific. // - // Support: Core - An optional single reference to a single Kubernetes Secret - // and to a single Kubernetes ConfigMap with the CA certificate in a key named `ca.crt`. + // Support: Core - A single reference to a single Kubernetes ConfigMap + // with the CA certificate in a key named `ca.crt`. // // Support: Implementation-specific (More than one reference, or other kinds // of resources). From 474db12316ee81b9a7abaad13b1aa1fc0d5a7b8b Mon Sep 17 00:00:00 2001 From: Arko Dasgupta Date: Fri, 5 Apr 2024 19:49:41 -0700 Subject: [PATCH 21/21] rm duplicate single word Signed-off-by: Arko Dasgupta --- geps/gep-91/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/geps/gep-91/index.md b/geps/gep-91/index.md index e04f1f75e4..cd5d50ea14 100644 --- a/geps/gep-91/index.md +++ b/geps/gep-91/index.md @@ -99,7 +99,7 @@ type FrontendTLSValidation struct { // Implementations MAY choose to support attaching multiple CA certificates to // a Listener, but this behavior is implementation-specific. // - // Support: Core - A single reference to a single Kubernetes ConfigMap + // Support: Core - A single reference to a Kubernetes ConfigMap // with the CA certificate in a key named `ca.crt`. // // Support: Implementation-specific (More than one reference, or other kinds