Elastic Docs ›Elasticsearch Service Documentation ›Securing your deployment
« Secure your clusters with JWT Traffic Filtering »

Trust managementedit

In order to establish a remote connection between two remote clusters, they must both trust each other. Trust is bi-directional: If one of the clusters doesn’t trust the other, the remote connection won’t be established.

Mutual trust between two clusters is required to enable cross-cluster search and cross-cluster replication.

Trust can be configured individually for each deployment.

Default trust with other clusters in the same Elasticsearch Service organizationedit

By default, any deployment that you create trusts all other deployments in the same organization. You can change this behavior in the Elasticsearch Service Console under Features > Trust, so that when a new deployment is created it does not trust any other deployment. You can choose one of the following options:

  • Trust all my deployments - New deployments will by default trust any other deployment from your organization (even deployments that don’t exist when the deployment is created).
  • Trust no deployment - New deployments won’t trust any other deployment when they are created. (This can be changed later in the deployment trust settings)
Trust management at the account Level

Note the following behaviours with this trust setting:

  • Changing the trust settings affects only deployments that you create in the future. The level of trust of existing deployments is not modified by this setting.
  • Deployments created before the Elasticsearch Service February 2021 release trust only themselves. You need to update the trust setting for each deployment that you want to either use as a remote cluster or configure to work with a remote cluster.

Update the trust settings of a deploymentedit

A deployment can be configured to trust all, specific, or no deployments in the same Elasticsearch Service organization, other Elasticsearch Service organizations, an Elastic Cloud Enterprise environment or self-managed environments.

This can be done in the Security page of your deployment:

  1. Log in to the Elasticsearch Service Console.

  2. Find your deployment on the home page in the Elasticsearch Service card and click the gear icon to access it directly. Or, select Elasticsearch Service to go to the deployments page to view all of your deployments.

    On the deployments page you can narrow your deployments by name, ID, or choose from several other filters. To customize your view, use a combination of filters, or change the format from a grid to a list.

  3. From the Security menu, find the Trusted deployments section.
Trusted Deployments at the Deployment Level

The page shows a list of all the deployments that this deployment trusts, grouped by environment or organization. Initially only your organization appears, but you can trust deployments in other Elasticsearch Service organizations, a remote Elastic Cloud Enterprise environment or any self-managed environment.

Configuring trust with clusters in the same Elasticsearch Service organizationedit

  1. From the list of existing trust configurations, edit the one labeled as your organization.

  2. Choose one of following options to configure the level of trust on each of your deployments:

    • All deployments - This deployment trusts all other deployments in your organization, including new deployments when they are created.
    • Specific deployments - Choose which of the existing deployments from your organization you want to trust.
    • None - No deployment from your organization is trusted.
Trust Management at the Deployment Level
Using the API

You can update a deployment using the appropriate trust settings for the elasticsearch payload. The current trust settings can be found in the path .resources.elasticsearch[0].info.settings.trust when calling:

curl -X GET -H "Authorization: ApiKey $EC_API_KEY" https://api.elastic-cloud.com/api/v1/deployments/$DEPLOYMENT_ID?show_settings=true

For example:

{
  "accounts": [
    {
      "account_id": "ec38dd0aa45f4a69909ca5c81c27138a",
      "trust_all": true
    }
  ]
}

The account_id above represents your organization, and therefore is the one to be used to update the trust level with deployments in the same organization. For example, to update the trust level of a deployment to trust only another deployment of the same organization with cluster ID cf659f7fe6164d9691b284ae36811be1, the trust settings in the body would look like this:

{
  "trust":{
    "accounts":[
      {
         "account_id":"ec38dd0aa45f4a69909ca5c81c27138a",
         "trust_all":false,
         "trust_allowlist":[
            "cf659f7fe6164d9691b284ae36811be1"
         ]
      }
    ]
  }
}

Configuring trust with clusters in other Elasticsearch Service organizationsedit

A deployment can be configured to trust all or specific deployments in another Elasticsearch Service organizations. To add cross-organization trust:

  1. From the Security menu, select Trusted deployments > Add trusted environment and select Elastic Cloud Organization
  2. Enter the ID of the organization with which you want to establish trust.

  3. Choose one of following options to configure the level of trust with the other organization:

    • All deployments - This deployment trusts all deployments in the other organization, including new deployments when they are created.
    • Specific deployments - Specify which of the existing deployments you want to trust in the other organization. The full Elasticsearch cluster ID must be entered for each remote cluster. The Elasticsearch Cluster ID can be found in the deployment overview page under Applications.
  4. Perform the same steps in the opposite direction, so that the deployments in both organizations are configured to trust each other.

Note that the organization ID and cluster IDs must be entered fully and correctly. For security reasons, no verification of the IDs is possible. If cross-organization trust does not appear to be working, double-checking the IDs is a good place to start.

Trust management for a different organization
Using the API

You can update a deployment using the appropriate trust settings for the elasticsearch payload.

In order to trust a deployment with cluster id cf659f7fe6164d9691b284ae36811be1 in another organization with Organization ID 1053523734, you need to update the trust settings with an additional account like this:

{
  "trust":{
    "accounts":[
      {
         "account_id":"ec38dd0aa45f4a69909ca5c81c27138a",
         "trust_all":true
      },
      {
         "account_id":"1053523734",
         "trust_all":false,
         "trust_allowlist":[
            "cf659f7fe6164d9691b284ae36811be1"
         ]
      }
    ]
  }
}

Configuring trust with clusters in an Elastic Cloud Enterprise environmentedit

A deployment can be configured to trust all or specific deployments in a remote ECE environment:

  1. From the Security menu, select Trusted deployments > Add trusted environment and select Elastic Cloud Enterprise.
  2. Enter the environment ID of the ECE environment (which can be found under Platform > Trust Management in your ECE administration UI).
  3. Upload the Certificate Authority of the ECE environment (which can be downloaded from Platform > Trust Management in your ECE administration UI).

  4. Choose one of following options to configure the level of trust with the ECE environment:

    • All deployments - This deployment trusts all deployments in the ECE environment, including new deployments when they are created.
    • Specific deployments - Specify which of the existing deployments you want to trust in the ECE environment. The full Elasticsearch cluster ID must be entered for each remote cluster. The Elasticsearch Cluster ID can be found in the deployment overview page under Applications.
  5. Configure the deployment in the ECE environment to trust this deployment, so that both deployments are configured to trust each other.

Note that the environment ID and cluster IDs must be entered fully and correctly. For security reasons, no verification of the IDs is possible. If cross-environment trust does not appear to be working, double-checking the IDs is a good place to start.

Using the API

You can update a deployment using the appropriate trust settings for the elasticsearch payload.

In order to trust a deployment with cluster id cf659f7fe6164d9691b284ae36811be1 in an ECE environment with environment ID 1053523734, you need to update the trust settings with an additional direct trust relationship like this:

{
  "trust":{
    "accounts":[
      {
         "account_id":"ec38dd0aa45f4a69909ca5c81c27138a",
         "trust_all":true
      }
    ],
    "direct": [
      {
        "type" : "ECE",
        "name" : "My ECE environment",
        "scope_id" : "1053523734",
        "certificates" : [
            {
                "pem" : "-----BEGIN CERTIFICATE-----\nMIIDTzCCA...H0=\n-----END CERTIFICATE-----"
            }
         ],
         "trust_all":false,
         "trust_allowlist":[
            "cf659f7fe6164d9691b284ae36811be1"
         ]
       }
    ]
  }
}

Configuring trust with clusters in a self-managed environmentedit

A deployment can be configured to trust all or specific deployments in any environment:

  1. From the Security menu, select Trusted deployments > Add trusted environment and select Self managed Elasticsearch.
  2. Upload the Certificate Authority of the self-managed environment (the one used to sign all the cluster certificates).

  3. Select the clusters to trust. There are two options here depending on the subject name of the certificates presented by the nodes in your self managed cluster:

    • Following the Elastic Cloud pattern. In Elastic Cloud, the certificates of all Elasticsearch nodes follow this convention: CN = {node_id}.node.{cluster_id}.cluster.{scope_id}. If you follow the same convention in your self-managed environment, then choose this option and you will be able to select all or specific clusters to trust.
    • If your clusters don’t follow the previous convention for the certificates subject name of your nodes, you can still specify the node name of each of the nodes that should be trusted by this deployment. (Keep in mind that following this convention will simplify the management of this cluster since otherwise this configuration will need to be updated every time the topology of your self-managed cluster changes along with the trust restriction file. For this reason, it is recommended migrating your cluster certificates to follow the previous convention).

Trust management will not work properly in clusters without an otherName value specified, as is the case by default in an out-of-the-box Elasticsearch installation. To have the Elasticsearch certutil generate new certificates with the otherName attribute, use the file input with the cn attribute as in the example below.

  1. Configure the self-managed cluster to trust this deployment, so that both deployments are configured to trust each other:

    • Download the Certificate Authority used to sign the certificates of your deployment nodes (it can be found in the Security page of your deployment)
    • Trust this CA either using the setting xpack.security.transport.ssl.certificate_authorities in elasticsearch.yml or by adding it to the trust store.

  2. Generate certificates with an otherName attribute using the Elasticsearch certutil. Create a file called instances.yaml with all the details of the nodes in your on-premise cluster like below. The dns and ip settings are optional, but cn is mandatory for use with the trust_restrictions path setting in the next step. Next, run ./bin/elasticsearch-certutil cert --ca elastic-stack-ca.p12 -in instances.yaml to create new certificates for all the nodes at once. You can then copy the resulting files into each node.

    instances:
  - name: "node1"
    dns: ["node1.mydomain.com"]
    ip: ["192.168.1.1"]
    cn: ["node1.node.1234567abcd.cluster.myscope.account"]
  - name: "node2"
    dns: ["node2.mydomain.com"]
    ip: ["192.168.1.2"]
    cn: ["node2.node.1234567abcd.cluster.myscope.account"]

  3. Restrict the trusted clusters to allow only the ones which your self-managed cluster should trust.

    • All the clusters in an Elastic Cloud region are signed by the same certificate authority. Therefore, adding this CA would make the self-managed cluster trust all the clusters in that region, including clusters from other organizations. This can be limited using the setting xpack.security.transport.ssl.trust_restrictions.path which points to a file that limits the certificates to trust based on their otherName-attribute.

    • For example, the following file would trust:

      • two specific clusters with the cluster IDs aaaabbbbaaaabbbb<1> and xxxxyyyyxxxxyyyy<2> from an organization with organization ID 1053523734
      • <3> any cluster from an organization with organization ID 83988631
      • <4> The nodes from its own cluster (whose certificates follow a different convention: CN = node1.example.com, CN = node2.example.com and CN = node3.example.com) 
  trust.subject_name:
  - *.node.aaaabbbbaaaabbbb.cluster.1053523734.account 
  - *.node.xxxxyyyyxxxxyyyy.cluster.1053523734.account 
  - *.node.*.cluster.83988631.account 
  - node*.example.com

Generate new node certificates for an entire cluster using the file input mode of the certutil.

Using the API

You can update a deployment using the appropriate trust settings for the elasticsearch payload.

In order to trust a cluster whose nodes present certificates with the subject names: "CN = node1.example.com", "CN = node2.example.com" and "CN = node3.example.com" in a self-managed environment, you could update the trust settings with an additional direct trust relationship like this:

{
  "trust":{
    "accounts":[
      {
         "account_id":"ec38dd0aa45f4a69909ca5c81c27138a",
         "trust_all":true
      }
    ],
    "direct": [
      {
        "type" : "generic",
        "name" : "My Self-managed environment",
        "additional_node_names" : ["node1.example.com", "node2.example.com", "node3.example.com",],
        "certificates" : [
            {
                "pem" : "-----BEGIN CERTIFICATE-----\nMIIDTzCCA...H0=\n-----END CERTIFICATE-----"
            }
         ],
         "trust_all":false
       }
    ]
  }
}
« Secure your clusters with JWT Traffic Filtering »