A newer version is available. For the latest information, see the current release documentation.
« Secure your clusters with Kerberos Deployment heap dumps »
Elastic Docs ›Elastic Cloud Enterprise Reference [3.5] ›Administering deployments

Trust management

edit

Trust management

edit

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 ECE environment

edit

By default, any deployment that you or your users create trusts all other deployments in the same Elastic Cloud Enterprise environment. You can change this behavior in the Cloud UI under Platform > Trust Management, 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 ECE environment (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 environment 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 Elastic Cloud Enterprise version 2.9.0 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 deployment

edit

A deployment can be configured to trust all, specific, or no deployments in the same ECE environment, other remote ECE environments, Elastic Cloud, or self-managed environments.

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

  1. Log into the Cloud UI.

  2. On the deployments page, select your deployment.

    Narrow the list by name, ID, or choose from several other filters. To further define the list, use a combination of filters.

  3. From the Security menu, find the Trust Management section.
Trusted Environments at the Deployment Level

The page shows a list of all the deployments that this deployment trusts, grouped by environment. Initially only the Local Environment appears, which represents the current ECE environment, but you can trust deployments in other ECE environments, in Elastic Cloud, or any self-managed environment.

Configuring trust with clusters in the same ECE environment

edit
  1. Edit the Local Environment trust level (this represents the current ECE environment).

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

    • Trust all deployments - This deployment trusts all other deployments in this ECE environment, including new deployments when they are created.
    • Trust specific deployments - Choose which of the existing deployments from your ECE environment you want to trust.
    • Trust no deployment - No deployment in this ECE environment 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 -k -X GET -H "Authorization: ApiKey $ECE_API_KEY" https://COORDINATOR_HOST:12443/api/v1/deployments/$DEPLOYMENT_ID?show_settings=true

For example:

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

The account_id above represents the only account in an ECE environment, and therefore is the one used to update the trust level with deployments in the current ECE environment. For example, to update the trust level to trust only the deployment 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 remote ECE environments

edit

In order to configure remote clusters in other ECE environments, you will first need to establish a bi-directional trust relationship between both ECE environments:

  1. Download the certificate and copy the environment ID from your first ECE environment under Platform > Trust Management > Trust parameters
  2. Create a new trust relationship in the other ECE environment under Platform > Trust Management > Trusted environments using the certificate and environment ID from the previous step
  3. Download the certificate and copy the environment ID from your second ECE environment and create a new trust relationship with those in the first ECE environment
Creation of trust relationships

Now, deployments in those environments will be able to configure trust with deployments in the other environment. Trust must always be bi-directional (local cluster must trust remote cluster and viceversa) and it can be configured in each deployment page, under Security > Trust Management:

  1. Select Add trusted environment to configure trust with deployments in another ECE environment whose trust relationship has been created in the previous step.
  2. For each trusted ECE environment you can edit the trust level to trust all deployments or just specific ones. For the specific ones option, you can introduce a list of Elasticsearch cluster IDs to trust from that ECE environment. The Elasticsearch Cluster ID can be found in the deployment overview page under Applications.
Trusted Environments at the Deployment Level
Using the API

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

Establishing the trust between the two Elastic Cloud Enterprise environments can be done using the trust relationships API. For example, the list of trusted environments can be obtained calling the list trust relationships endpoint:

curl -k -X GET -H "Authorization: ApiKey $ECE_API_KEY" https://COORDINATOR_HOST:12443//api/v1/regions/ece-region/platform/configuration/trust-relationships?include_certificate=false

For each remote ECE environment, it will return something like this:

{
   "id":"83a7b03f2a4343fe99f09bd27ca3d9ec",
   "name":"ECE2",
   "trust_by_default":false,
   "account_ids":[
      "651598b101e54ccab1bfdcd8b6e3b8be"
   ],
   "local":false,
   "last_modified":"2022-01-9T14:33:20.465Z"
}

In order to trust a deployment with cluster id 123456789 in this environment named ECE2, you need to update the trust settings with an external trust relationship like this:

{
  "trust":{
    "accounts":[
      {
         "account_id":"ec38dd0aa45f4a69909ca5c81c27138a",
         "trust_all":true
      }
    ],
    "external":[
      {
         "trust_relationship_id":"83a7b03f2a4343fe99f09bd27ca3d9ec",
         "trust_all":false,
         "trust_allowlist":[
            "123456789"
         ]
      }
    ]
  }
}

Configuring trust with clusters in Elastic Cloud

edit

A deployment can be configured to trust all or specific deployments from an organization in Elastic Cloud:

  1. From the Security menu, select Trusted deployments > Add trusted environment and select Elastic Cloud Organization.
  2. Enter the organization ID (which can be found near the organization name).
  3. Upload the Certificate Authorities of the deployments you want to trust. These can be downloaded from the Security page of each deployment (not only the current CA, but also future certificates in case they are expiring soon since they are periodically rotated). Deployments from the same region are signed by the same CA, so you will only need to upload one for each region.

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

    • All deployments - This deployment trusts all deployments in the organization in the regions whose certificate authorities have been uploaded, including new deployments when they are created.
    • Specific deployments - Specify which of the existing deployments you want to trust from this 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.
  5. Configure the deployment in Elastic Cloud to trust this deployment, so that both deployments 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-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 organization with organization ID 803289842, 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" : "ESS",
        "name" : "My Organization",
        "scope_id" : "803289842",
        "certificates" : [
            {
                "pem" : "-----BEGIN CERTIFICATE-----\nMIIDTzCCA...H0=\n-----END CERTIFICATE-----"
            }
         ],
         "trust_all":false,
         "trust_allowlist":[
            "cf659f7fe6164d9691b284ae36811be1"
         ]
       }
    ]
  }
}

Configuring trust with clusters in a self-managed environment

edit

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 a CN value specified, as is the case by default in an out-of-the-box Elasticsearch installation.

  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. Restrict the trusted clusters to allow only the ones which your self-managed cluster should trust.

    • All the clusters in your Elastic Cloud Enterprise environment are signed by the same certificate authority. Therefore, adding this CA would make the self-managed cluster trust all your clusters in your ECE environment. This should be limited using the setting xpack.security.transport.ssl.trust_restrictions.path in elasticsearch.yml, which points to a file that limits the certificates to trust based on their subject name.

    • For example, the following file would trust:

      • two specific clusters with cluster ids aaaabbbbaaaabbbb<1> and xxxxyyyyxxxxyyyy<2> in an ECE environment with Environment ID 1053523734:
      • <3> any cluster from an ECE environment with Environment 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
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 Kerberos Deployment heap dumps »