Strong identity verification on Elastic Cloud Hosted

Starting with Elastic Stack 9.3, the API key security model for remote cluster connections supports strong identity verification. This adds an extra layer of security by allowing an API key to be used only by requests that present an allowed certificate identity, which the remote cluster validates during authentication.

This document describes how to enable strong identity verification for Elastic Cloud Hosted deployments and is intended to augment the standard remote cluster setup tutorials. While following the steps to configure remote clusters with API key authentication, apply the additional settings and procedures described here. Some settings can be applied independently, while others note the stage in the procedure where you should apply them.

Both the local and remote clusters must run Elastic Stack 9.3 or later to use strong identity verification.

To use strong identity verification, both the local and remote clusters must be configured to sign and verify cross-cluster request headers. All settings described in this guide are dynamic and can be configured using the cluster settings API or as static elasticsearch.yml configuration settings.

For a full list of available strong identity verification settings for remote clusters, refer to the remote cluster settings reference.

When adding the remote cluster to the local cluster, you must configure it to sign cross-cluster requests with a TLS certificate–private key pair. You can either generate and use your own certificate for this purpose or reuse an existing certificate.

This example configures the local cluster to use the existing transport certificates to sign cross-cluster requests. These certificate files are present in all Elastic Cloud deployments:

cluster.remote.<my_remote_cluster>.signing.certificate: "node.crt"
cluster.remote.<my_remote_cluster>.signing.key: "node.key"
		

1. Replace <my_remote_cluster> with your remote cluster alias.

If you use your own certificates, upload the certificate and key files as a ZIP bundle and reference them in the settings:

cluster.remote.<my_remote_cluster>.signing.certificate: "/app/config/<bundle-zip-directory>/<signing-cert.crt>"
cluster.remote.<my_remote_cluster>.signing.key: "/app/config/<bundle-zip-directory>/<signing-key.key>"
		

1. Replace <my_remote_cluster> with your remote cluster alias, and the paths with the paths to your certificate and key files included in the bundle.

The certificate and key used by the local cluster to sign cross-cluster requests determine how the remote cluster must be configured. Specifically:

1. Add the certificate authority (CA) that issued the local cluster certificate to the cluster.remote.signing.certificate_authorities setting of the remote cluster:

   cluster.remote.signing.certificate_authorities: "internal_tls_ca.crt"
   		

   1. This example uses the regional CA certificate file that is available in all Elastic Cloud deployments. This CA is unique per Elastic Cloud region and cloud provider.

   The CA file to configure depends on how the local cluster is set up:

   • If the local cluster uses the default transport certificates, and both the local and remote clusters belong to the same cloud provided and region on Elastic Cloud, you can use the internal_tls_ca.crt file that already exist in your cluster. No additional upload is required.

   • If the local cluster uses the default transport certificates, but the remote cluster belongs to a different Elastic Cloud provider or region, you must download the local cluster transport CA and upload it to the remote deployment as a bundle. To do that:

     1. Open your deployment management page in the Elastic Cloud UI and go to Security.
     2. Under CA certificates, select the download icon to save the CA into a local file.
     3. Add the CA certificate as a ZIP bundle in your remote deployment, and reference the file in the cluster.remote.signing.certificate_authorities setting.

   • If you use custom certificates in the local cluster, upload the associated CA to the remote cluster as a ZIP bundle, and reference the file in the cluster.remote.signing.certificate_authorities setting.

2. When creating the cross-cluster API key on the remote cluster, you must specify a certificate_identity pattern that matches the Distinguished Name (DN) of the certificate used by the local cluster.

   Tip

   In Elastic Cloud, the certificates of all Elasticsearch nodes follow this Distinguished Name (DN) format:
   CN=<node_id>.node.<cluster_id>.cluster.<scope_id>.

   • The Elasticsearch cluster_id of your deployment can be found on the deployment page in the Elastic Cloud UI by selecting Copy cluster ID.
   • The scope_id corresponds to the Elastic Cloud organization ID.

   This example creates a cross-cluster API key with a certificate_identity pattern that matches the default Elastic Cloud transport certificates for a specific cluster_id:

   				POST /_security/cross_cluster/api_key
   					{
     "name": "my-cross-cluster-api-key",
     "access": {
       "search": [
         {
           "names": ["logs-*"]
         }
       ]
     },
     "certificate_identity": "CN=.*.node.<cluster-id>.cluster.*"
   }
   		

   1. If the local cluster uses custom certificates, adjust the pattern to match their DN instead.

   The certificate_identity field supports regular expressions that are matched against the certificate DN. For example:

   • "CN=.*.example.com,O=Example Corp,C=US" matches any certificate whose DN starts with a CN that ends in example.com and includes O=Example Corp,C=US.
   • "CN=local-cluster.*,O=Example Corp,C=US" matches any certificate whose DN starts with CN=local-cluster and includes O=Example Corp,C=US.
   • "CN=.*.node.<cluster-id>.cluster.*" matches the Elastic Cloud transport certificates for a given cluster_id.
   • "CN=.*.node.*.cluster.<org-id>" matches the Elastic Cloud transport certificates for all clusters in a given ECH organization.