| 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194 | [[remote-clusters-api-key]]=== Add remote clusters using API key authenticationcoming::[8.10]beta::[]API key authentication enables a local cluster to authenticate itself with aremote cluster via a <<security-api-create-cross-cluster-api-key,cross-clusterAPI key>>. The API key needs to be created by an administrator of the remotecluster. The local cluster is configured to provide this API key on each requestto the remote cluster. The remote cluster verifies the API key and grantsaccess, based on the API key's privileges.All cross-cluster requests from the local cluster are bound by the API key'sprivileges, regardless of local users associated with the requests. For example,if the API key only allows read access to `my-index` on the remote cluster, evena superuser from the local cluster is limited by this constraint. This mechanismenables the remote cluster's administrator to have full control over who canaccess what data with cross-cluster search and/or cross-cluster replication. Theremote cluster's administrator can be confident that no access is possiblebeyond what is explicitly assigned to the API key.On the local cluster side, not every local user needs to access every piece ofdata allowed by the API key. An administrator of the local cluster can furtherconfigure additional permission constraints on local users so each user onlygets access to the necessary remote data. Note it is only possible to furtherreduce the permissions allowed by the API key for individual local users. It isimpossible to increase the permissions to go beyond what is allowed by the APIkey.In this model, cross-cluster operations use <<remote_cluster.port,a dedicatedserver port>> (remote cluster interface) for communication between clusters. Aremote cluster must enable this port for local clusters to connect. ConfigureTransport Layer Security (TLS) for this port to maximize security (as explainedin <<remote-clusters-security-api-key>>). The local cluster must trust the remote cluster on the remote cluster interface.This means that the local cluster trusts the remote cluster's certificateauthority (CA) that signs the server certificate used by the remote clusterinterface. When establishing a connection, all nodes from the local cluster thatparticipate in cross-cluster communication verify certificates from nodes on theother side, based on the TLS trust configuration.To add a remote cluster using API key authentication:. <<remote-clusters-prerequisites-api-key,Review the prerequisites>>. <<remote-clusters-security-api-key>>. <<remote-clusters-connect-api-key>>. <<remote-clusters-privileges-api-key>>[[remote-clusters-prerequisites-api-key]]==== Prerequisites* The {es} security features need to be enabled on both clusters, on every node.Security is enabled by default. If it's disabled, set `xpack.security.enabled`to `true` in `elasticsearch.yml`. Refer to <<general-security-settings>>.* The nodes of the local and remote clusters must be on version 8.10 or later.* The local and remote clusters must have an appropriate license. For moreinformation, refer to https://www.elastic.co/subscriptions.[[remote-clusters-security-api-key]]==== Establish trust with a remote cluster===== On the remote cluster// tag::remote-cluster-steps[]. Enable the remote cluster server on every node of the remote cluster. In `elasticsearch.yml`:.. Set <<remote-cluster-network-settings,`remote_cluster_server.enabled`>> to `true`... Configure the bind and publish address for remote cluster server traffic, forexample using <<remote-cluster-network-settings,`remote_cluster.host`>>. Withoutconfiguring the address, remote cluster traffic may be bound to the localinterface, and remote clusters running on other machines can't connect... Optionally, configure the remote server port using <<remote_cluster.port,`remote_cluster.port`>> (defaults to `9443`).. Next, generate a certificate authority (CA) and a server certificate/key pair.On one of the nodes of the remote cluster, from the directory where {es} hasbeen installed:.. Create a CA, if you don't have a CA already:+[source,sh]----./bin/elasticsearch-certutil ca --pem --out=cross-cluster-ca.zip --pass CA_PASSWORD----+Replace `CA_PASSWORD` with the password you want to use for the CA. You can remove the `--pass` option and its argument if you are not deploying to a production environment... Unzip the generated `cross-cluster-ca.zip` file. This compressed filecontains the following content:+[source,txt]----/ca|_ ca.crt|_ ca.key----.. Generate a certificate and private key pair for the nodes in the remote cluster:+[source,sh]----./bin/elasticsearch-certutil cert --out=cross-cluster.p12 --pass=CERT_PASSWORD --ca-cert=ca/ca.crt --ca-key=ca/ca.key --ca-pass=CA_PASSWORD --dns=example.com --ip=127.0.0.1----+* Replace `CA_PASSWORD` with the CA password from the previous step.* Replace `CERT_PASSWORD` with the password you want to use for the generatedprivate key.* Use the `--dns` option to specify the relevant DNS name for the certificate.You can specify it multiple times for multiple DNS.* Use the `--ip` option to specify the relevant IP address for the certificate.You can specify it multiple times for multiple IP addresses... If the remote cluster has multiple nodes, you can either:+* create a single wildcard certificate for all nodes;* or, create separate certificates for each node either manually or in batchwith the <<certutil-silent,silent mode>>.. On every node of the remote cluster:.. Copy the `cross-cluster.p12` file from the earlier step to the `config`directory. If you didn't create a wildcard certificate, make sure you copy thecorrect node-specific p12 file... Add following configuration to `elasticsearch.yml`:+[source,yaml]----xpack.security.remote_cluster_server.ssl.enabled: truexpack.security.remote_cluster_server.ssl.keystore.path: cross-cluster.p12----.. Add the SSL keystore password to the {es} keystore:+[source,sh]----./bin/elasticsearch-keystore add xpack.security.remote_cluster_server.ssl.keystore.secure_password----+When prompted, enter the `CERT_PASSWORD` from the earlier step.. Restart the remote cluster.. On the remote cluster, generate a cross-cluster API key that provides accessto the indices you want to use for {ccs} or {ccr}. You can use the<<security-api-create-cross-cluster-api-key>> API or{kibana-ref}/api-keys.html[Kibana].. Copy the encoded key (`encoded` in the response) to a safe location. You willneed it to connect to the remote cluster later.// end::remote-cluster-steps[]===== On the local cluster// tag::local-cluster-steps[]. On every node of the local cluster:.. Copy the `ca.crt` file generated on the remote cluster earlier into the`config` directory, renaming the file `remote-cluster-ca.crt`... Add following configuration to `elasticsearch.yml`:+[source,yaml]----xpack.security.remote_cluster_client.ssl.enabled: truexpack.security.remote_cluster_client.ssl.certificate_authorities: [ "remote-cluster-ca.crt" ]----// end::local-cluster-steps[].. Add the cross-cluster API key, created on the remote cluster earlier, to thekeystore:+[source,sh]----./bin/elasticsearch-keystore add cluster.remote.ALIAS.credentials----+Replace `ALIAS` with the alias you will use to connect to the remote clusterlater. When prompted, enter the encoded cross-cluster API key created on theremote cluster earlier.. Restart the local cluster to load the keystore change.[[remote-clusters-connect-api-key]]==== Connect to a remote cluster:trust-mechanism: api-keyinclude::remote-clusters-connect.asciidoc[]:!trust-mechanism: include::../../../../x-pack/docs/en/security/authentication/remote-clusters-privileges-api-key.asciidoc[leveloffset=+1]
 |