Allow custom certificates on the transport layer #6727
Conversation
docs/orchestrating-elastic-stack-applications/elasticsearch/remote-clusters.asciidoc
Show resolved
Hide resolved
|
buildkite test this -f p=gke,t=TestCustomTransportCA -m s=8.7.1,s=8.8.0-SNAPSHOT^BUILD_LICENSE_PUBKEY=dev |
|
Test failed due to Google outage |
|
buildkite test this -f p=gke,t=TestCustomTransportCA -m s=8.8.0-SNAPSHOT^BUILD_LICENSE_PUBKEY=dev |
docs/orchestrating-elastic-stack-applications/elasticsearch/transport-settings.asciidoc
Outdated
Show resolved
Hide resolved
| csi.cert-manager.io/dns-names: "${POD_NAME}.${POD_NAMESPACE}.svc.cluster.local" | ||
| ---- | ||
|
|
||
| The example assumes that a `ClusterIssuer` by the name of `ca-cluster-issuer` exists and that a trust bundle containing the PEM encoded CA certificate is available in a file called `ca.crt` in a ConfigMap called `trust` in the same namespace as the Elasticsearch resource. The following section is only provided to illustrate how these certificates can be configured in principle: |
There was a problem hiding this comment.
nit: not sure how this can be improved, but this sentence seems a bit long, with a lot of in .. in ... in ... 😄
| @@ -172,6 +172,9 @@ type TransportTLSOptions struct { | |||
| // - `ca.crt`: The CA certificate in PEM format. | |||
| // - `ca.key`: The private key for the CA certificate in PEM format. | |||
| Certificate commonv1.SecretRef `json:"certificate,omitempty"` | |||
| // CertificateAuthorities is a references to a config map that contains one or more x509 certificates for | |||
| // trusted authorities in PEM format. The certificates need to be in a file called `ca.crt`. | |||
There was a problem hiding this comment.
I wonder if there are cases where the name of the key is not under the control of the user. For example the CA key name from the OpenShift CA service is service-ca.crt:
Other services can request that the CA bundle for the service CA be injected into API service or config map resources by annotating with service.beta.openshift.io/inject-cabundle: true to support validating certificates generated from the service CA. In response, the Operator writes its current CA bundle to the CABundle field of an API service or as service-ca.crt to a config map
I don't think however that the OpenShift CA service can be used to manage the transport certificates, so it's not a valid example. And we can offer a first implementation where the expected key is ca.crt, and later add a new field to select a different key:
transport:
tls:
certificateAuthorities:
configMapName: trust
keys: ## Optional, ca.crt by default
- service-ca.crt
docs/orchestrating-elastic-stack-applications/elasticsearch/transport-settings.asciidoc
Outdated
Show resolved
Hide resolved
|
@pebrc I'll cut the 2.8 branch in a bit, let me know if you want to get this one into the next release 🙇 |
|
Sorry. I will merge this now. I could have sworn I had already hit the button a few days ago ... |
Fixes #6479
Introduce a new attribute
transport.tls.certificateAuthorities.configMapNamewhich expects a config map with aca.crtfile that can contain one or more CAs in PEM format. Alternative name suggestiontransport.tls.trustConcatenate these additional CAs with the CA issued by ECK in the internal and public secrets. This ensures that all existing mechanisms including remote cluster support seamlessly pick up the additional trust. It also allows transitioning without downtime from self-issued certificates to third-party issued certificates.
Adds a documentation section to illustrate how transport certificates can be configured with cert-manager csi-driver (arguably could also be a recipe but not one we auto-test because of the additional infrastructure requirements)
Despite declaring my intention to add a similar attribute to the HTTP options I did not go through with it. I don't see the same need given that the HTTP certificate is effectively a server certificate and we have an existing mechanism through associations to establish trust. Also HTTP options are shared across all stack applications and thus this change has a much larger scope. We can follow up in a separate PR if reviewers think it useful.