remote-clusters-api-key.asciidoc 8.3 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201
  1. [[remote-clusters-api-key]]
  2. === Add remote clusters using API key authentication
  3. API key authentication enables a local cluster to authenticate itself with a
  4. remote cluster via a <<security-api-create-cross-cluster-api-key,cross-cluster
  5. API key>>. The API key needs to be created by an administrator of the remote
  6. cluster. The local cluster is configured to provide this API key on each request
  7. to the remote cluster. The remote cluster verifies the API key and grants
  8. access, based on the API key's privileges.
  9. All cross-cluster requests from the local cluster are bound by the API key's
  10. privileges, regardless of local users associated with the requests. For example,
  11. if the API key only allows read access to `my-index` on the remote cluster, even
  12. a superuser from the local cluster is limited by this constraint. This mechanism
  13. enables the remote cluster's administrator to have full control over who can
  14. access what data with cross-cluster search and/or cross-cluster replication. The
  15. remote cluster's administrator can be confident that no access is possible
  16. beyond what is explicitly assigned to the API key.
  17. On the local cluster side, not every local user needs to access every piece of
  18. data allowed by the API key. An administrator of the local cluster can further
  19. configure additional permission constraints on local users so each user only
  20. gets access to the necessary remote data. Note it is only possible to further
  21. reduce the permissions allowed by the API key for individual local users. It is
  22. impossible to increase the permissions to go beyond what is allowed by the API
  23. key.
  24. In this model, cross-cluster operations use <<remote_cluster.port,a dedicated
  25. server port>> (remote cluster interface) for communication between clusters. A
  26. remote cluster must enable this port for local clusters to connect. Configure
  27. Transport Layer Security (TLS) for this port to maximize security (as explained
  28. in <<remote-clusters-security-api-key>>).
  29. The local cluster must trust the remote cluster on the remote cluster interface.
  30. This means that the local cluster trusts the remote cluster's certificate
  31. authority (CA) that signs the server certificate used by the remote cluster
  32. interface. When establishing a connection, all nodes from the local cluster that
  33. participate in cross-cluster communication verify certificates from nodes on the
  34. other side, based on the TLS trust configuration.
  35. To add a remote cluster using API key authentication:
  36. . <<remote-clusters-prerequisites-api-key,Review the prerequisites>>
  37. . <<remote-clusters-security-api-key>>
  38. . <<remote-clusters-connect-api-key>>
  39. . <<remote-clusters-privileges-api-key>>
  40. If you run into any issues, refer to <<remote-clusters-troubleshooting>>.
  41. [[remote-clusters-prerequisites-api-key]]
  42. ==== Prerequisites
  43. * The {es} security features need to be enabled on both clusters, on every node.
  44. Security is enabled by default. If it's disabled, set `xpack.security.enabled`
  45. to `true` in `elasticsearch.yml`. Refer to <<general-security-settings>>.
  46. * The nodes of the local and remote clusters must be on version 8.10 or later.
  47. * The local and remote clusters must have an appropriate license. For more
  48. information, refer to https://www.elastic.co/subscriptions.
  49. [[remote-clusters-security-api-key]]
  50. ==== Establish trust with a remote cluster
  51. NOTE: If a remote cluster is part of an {ess} deployment, it has a valid certificate by default.
  52. You can therefore skip steps related to certificates in these instructions.
  53. [[remote-clusters-security-api-key-remote-action]]
  54. ===== On the remote cluster
  55. // tag::remote-cluster-steps[]
  56. . Enable the remote cluster server on every node of the remote cluster. In
  57. `elasticsearch.yml`:
  58. .. Set <<remote-cluster-network-settings,`remote_cluster_server.enabled`>> to
  59. `true`.
  60. .. Configure the bind and publish address for remote cluster server traffic, for
  61. example using <<remote-cluster-network-settings,`remote_cluster.host`>>. Without
  62. configuring the address, remote cluster traffic may be bound to the local
  63. interface, and remote clusters running on other machines can't connect.
  64. .. Optionally, configure the remote server port using
  65. <<remote_cluster.port,`remote_cluster.port`>> (defaults to `9443`).
  66. . Next, generate a certificate authority (CA) and a server certificate/key pair.
  67. On one of the nodes of the remote cluster, from the directory where {es} has
  68. been installed:
  69. .. Create a CA, if you don't have a CA already:
  70. +
  71. [source,sh]
  72. ----
  73. ./bin/elasticsearch-certutil ca --pem --out=cross-cluster-ca.zip --pass CA_PASSWORD
  74. ----
  75. +
  76. Replace `CA_PASSWORD` with the password you want to use for the CA. You can
  77. remove the `--pass` option and its argument if you are not deploying to a
  78. production environment.
  79. .. Unzip the generated `cross-cluster-ca.zip` file. This compressed file
  80. contains the following content:
  81. +
  82. [source,txt]
  83. ----
  84. /ca
  85. |_ ca.crt
  86. |_ ca.key
  87. ----
  88. .. Generate a certificate and private key pair for the nodes in the remote
  89. cluster:
  90. +
  91. [source,sh]
  92. ----
  93. ./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
  94. ----
  95. +
  96. * Replace `CA_PASSWORD` with the CA password from the previous step.
  97. * Replace `CERT_PASSWORD` with the password you want to use for the generated
  98. private key.
  99. * Use the `--dns` option to specify the relevant DNS name for the certificate.
  100. You can specify it multiple times for multiple DNS.
  101. * Use the `--ip` option to specify the relevant IP address for the certificate.
  102. You can specify it multiple times for multiple IP addresses.
  103. .. If the remote cluster has multiple nodes, you can either:
  104. +
  105. * create a single wildcard certificate for all nodes;
  106. * or, create separate certificates for each node either manually or in batch
  107. with the <<certutil-silent,silent mode>>.
  108. . On every node of the remote cluster:
  109. .. Copy the `cross-cluster.p12` file from the earlier step to the `config`
  110. directory. If you didn't create a wildcard certificate, make sure you copy the
  111. correct node-specific p12 file.
  112. .. Add following configuration to `elasticsearch.yml`:
  113. +
  114. [source,yaml]
  115. ----
  116. xpack.security.remote_cluster_server.ssl.enabled: true
  117. xpack.security.remote_cluster_server.ssl.keystore.path: cross-cluster.p12
  118. ----
  119. .. Add the SSL keystore password to the {es} keystore:
  120. +
  121. [source,sh]
  122. ----
  123. ./bin/elasticsearch-keystore add xpack.security.remote_cluster_server.ssl.keystore.secure_password
  124. ----
  125. +
  126. When prompted, enter the `CERT_PASSWORD` from the earlier step.
  127. . Restart the remote cluster.
  128. . On the remote cluster, generate a cross-cluster API key that provides access
  129. to the indices you want to use for {ccs} or {ccr}. You can use the
  130. <<security-api-create-cross-cluster-api-key>> API or
  131. {kibana-ref}/api-keys.html[Kibana].
  132. . Copy the encoded key (`encoded` in the response) to a safe location. You will
  133. need it to connect to the remote cluster later.
  134. // end::remote-cluster-steps[]
  135. [[remote-clusters-security-api-key-local-actions]]
  136. ===== On the local cluster
  137. // tag::local-cluster-steps[]
  138. . On every node of the local cluster:
  139. .. Copy the `ca.crt` file generated on the remote cluster earlier into the
  140. `config` directory, renaming the file `remote-cluster-ca.crt`.
  141. .. Add following configuration to `elasticsearch.yml`:
  142. +
  143. [source,yaml]
  144. ----
  145. xpack.security.remote_cluster_client.ssl.enabled: true
  146. xpack.security.remote_cluster_client.ssl.certificate_authorities: [ "remote-cluster-ca.crt" ]
  147. ----
  148. // end::local-cluster-steps[]
  149. .. Add the cross-cluster API key, created on the remote cluster earlier, to the
  150. keystore:
  151. +
  152. [source,sh]
  153. ----
  154. ./bin/elasticsearch-keystore add cluster.remote.ALIAS.credentials
  155. ----
  156. +
  157. Replace `ALIAS` with the same name that you will use to create the remote cluster entry
  158. later. When prompted, enter the encoded cross-cluster API key created on the
  159. remote cluster earlier.
  160. . Restart the local cluster to load changes to the keystore and settings.
  161. **Note:** If you are configuring only the cross-cluster API key, you can call the <<cluster-nodes-reload-secure-settings>> API, instead of restarting the cluster.
  162. Configuring the `remote_cluster_client` settings in `elasticsearch.yml` still requires a restart.
  163. [[remote-clusters-connect-api-key]]
  164. ==== Connect to a remote cluster
  165. :trust-mechanism: api-key
  166. include::remote-clusters-connect.asciidoc[]
  167. :!trust-mechanism:
  168. include::{es-ref-dir}/security/authentication/remote-clusters-privileges-api-key.asciidoc[leveloffset=+1]