cross-cluster.asciidoc 4.6 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157
  1. [[cross-cluster-configuring]]
  2. === {ccs-cap} and security
  3. <<modules-cross-cluster-search,{ccs-cap}>> enables
  4. federated search across multiple clusters. When using cross cluster search
  5. with secured clusters, all clusters must have the {es} {security-features}
  6. enabled.
  7. The local cluster (the cluster used to initiate cross cluster search) must be
  8. allowed to connect to the remote clusters, which means that the CA used to
  9. sign the SSL/TLS key of the local cluster must be trusted by the remote
  10. clusters.
  11. User authentication is performed on the local cluster and the user and user's
  12. roles are passed to the remote clusters. A remote cluster checks the user's
  13. roles against its local role definitions to determine which indices the user
  14. is allowed to access.
  15. [WARNING]
  16. This feature was added as Beta in {es} `v5.3` with further improvements made in
  17. 5.4 and 5.5. It requires gateway eligible nodes to be on `v5.5` onwards.
  18. To use cross cluster search with secured clusters:
  19. * Enable the {es} {security-features} on every node in each connected cluster.
  20. For more information about the `xpack.security.enabled` setting, see
  21. <<security-settings>>.
  22. * Enable encryption globally. To encrypt communications, you must enable
  23. <<encrypt-internode-communication,enable SSL/TLS>> on every node.
  24. * Enable a trust relationship between the cluster used for performing cross
  25. cluster search (the local cluster) and all remote clusters. This can be done
  26. either by:
  27. +
  28. ** Using the same certificate authority to generate certificates for all
  29. connected clusters, or
  30. ** Adding the CA certificate from the local cluster as a trusted CA in
  31. each remote cluster (see <<transport-tls-ssl-settings>>).
  32. * On the local cluster, ensure that users are assigned to (at least) one role
  33. that exists on the remote clusters. On the remote clusters, use that role
  34. to define which indices the user may access. (See <<authorization>>).
  35. * Configure the local cluster to connect to remote clusters as described
  36. in <<configuring-remote-clusters>>.
  37. For example, the following configuration adds two remote clusters
  38. to the local cluster:
  39. +
  40. --
  41. [source,console]
  42. -----------------------------------------------------------
  43. PUT _cluster/settings
  44. {
  45. "persistent": {
  46. "cluster": {
  47. "remote": {
  48. "one": {
  49. "seeds": [ "10.0.1.1:9300" ]
  50. },
  51. "two": {
  52. "seeds": [ "10.0.2.1:9300" ]
  53. }
  54. }
  55. }
  56. }
  57. }
  58. -----------------------------------------------------------
  59. --
  60. [[cross-cluster-configuring-example]]
  61. ==== Example configuration of cross cluster search
  62. In the following example, we will configure the user `alice` to have permissions
  63. to search any data stream or index starting with `logs-` in cluster `two` from
  64. cluster `one`.
  65. First, enable cluster `one` to perform cross cluster search on remote cluster
  66. `two` by running the following request as the superuser on cluster `one`:
  67. [source,console]
  68. -----------------------------------------------------------
  69. PUT _cluster/settings
  70. {
  71. "persistent": {
  72. "cluster.remote.two.seeds": [ "10.0.2.1:9300" ]
  73. }
  74. }
  75. -----------------------------------------------------------
  76. Next, set up a role called `cluster_two_logs` on both cluster `one` and
  77. cluster `two`.
  78. On cluster `one`, this role does not need any special privileges:
  79. [source,console]
  80. -----------------------------------------------------------
  81. POST /_security/role/cluster_two_logs
  82. {
  83. }
  84. -----------------------------------------------------------
  85. On cluster `two`, this role allows the user to query local indices called
  86. `logs-` from a remote cluster:
  87. [source,console]
  88. -----------------------------------------------------------
  89. POST /_security/role/cluster_two_logs
  90. {
  91. "cluster": [],
  92. "indices": [
  93. {
  94. "names": [
  95. "logs-*"
  96. ],
  97. "privileges": [
  98. "read",
  99. "read_cross_cluster"
  100. ]
  101. }
  102. ]
  103. }
  104. -----------------------------------------------------------
  105. Finally, create a user on cluster `one` and apply the `cluster_two_logs` role:
  106. [source,console]
  107. -----------------------------------------------------------
  108. POST /_security/user/alice
  109. {
  110. "password" : "somepasswordhere",
  111. "roles" : [ "cluster_two_logs" ],
  112. "full_name" : "Alice",
  113. "email" : "alice@example.com",
  114. "enabled": true
  115. }
  116. -----------------------------------------------------------
  117. With all of the above setup, the user `alice` is able to search indices in
  118. cluster `two` as follows:
  119. [source,console]
  120. -----------------------------------------------------------
  121. GET two:logs-2017.04/_search
  122. {
  123. "query": {
  124. "match_all": {}
  125. }
  126. }
  127. -----------------------------------------------------------
  128. // TEST[skip:todo]
  129. include::cross-cluster-kibana.asciidoc[]