remote-clusters-privileges-cert.asciidoc 8.5 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302
  1. [[remote-clusters-privileges-cert]]
  2. === Configure roles and users for remote clusters
  3. After <<remote-clusters-connect,connecting remote clusters>>, you create a
  4. user role on both the local and remote clusters and assign necessary privileges.
  5. These roles are required to use {ccr} and {ccs}.
  6. IMPORTANT: You must use the same role names on both the local
  7. and remote clusters. For example, the following configuration for {ccr} uses the
  8. `remote-replication` role name on both the local and remote clusters. However,
  9. you can specify different role definitions on each cluster.
  10. You can manage users and roles from Stack Management in {kib} by selecting
  11. *Security > Roles* from the side navigation. You can also use the
  12. <<security-role-mapping-apis,role management APIs>> to add, update, remove, and
  13. retrieve roles dynamically. When you use the APIs to manage roles in the
  14. `native` realm, the roles are stored in an internal {es} index.
  15. The following requests use the
  16. <<security-api-put-role,create or update roles API>>. You must have at least the
  17. `manage_security` cluster privilege to use this API.
  18. [[remote-clusters-privileges-ccr]]
  19. //tag::configure-ccr-privileges[]
  20. ==== Configure privileges for {ccr}
  21. The {ccr} user requires different cluster and index privileges on the remote
  22. cluster and local cluster. Use the following requests to create separate roles
  23. on the local and remote clusters, and then create a user with the required
  24. roles.
  25. [discrete]
  26. ===== Remote cluster
  27. On the remote cluster that contains the leader index, the {ccr} role requires
  28. the `read_ccr` cluster privilege, and `monitor` and `read` privileges on the
  29. leader index.
  30. NOTE: If requests are authenticated with an <<security-api-create-api-key, API key>>, the API key
  31. requires the above privileges on the **local** cluster, instead of the remote.
  32. NOTE: If requests are issued <<run-as-privilege,on behalf of other users>>,
  33. then the authenticating user must have the `run_as` privilege on the remote
  34. cluster.
  35. The following request creates a `remote-replication` role on the remote cluster:
  36. [source,console]
  37. ----
  38. POST /_security/role/remote-replication
  39. {
  40. "cluster": [
  41. "read_ccr"
  42. ],
  43. "indices": [
  44. {
  45. "names": [
  46. "leader-index-name"
  47. ],
  48. "privileges": [
  49. "monitor",
  50. "read"
  51. ]
  52. }
  53. ]
  54. }
  55. ----
  56. ////
  57. [source,console]
  58. ----
  59. DELETE /_security/role/remote-replication
  60. ----
  61. // TEST[continued]
  62. ////
  63. [discrete]
  64. ===== Local cluster
  65. On the local cluster that contains the follower index, the `remote-replication`
  66. role requires the `manage_ccr` cluster privilege, and `monitor`, `read`, `write`,
  67. and `manage_follow_index` privileges on the follower index.
  68. The following request creates a `remote-replication` role on the local cluster:
  69. [source,console]
  70. ----
  71. POST /_security/role/remote-replication
  72. {
  73. "cluster": [
  74. "manage_ccr"
  75. ],
  76. "indices": [
  77. {
  78. "names": [
  79. "follower-index-name"
  80. ],
  81. "privileges": [
  82. "monitor",
  83. "read",
  84. "write",
  85. "manage_follow_index"
  86. ]
  87. }
  88. ]
  89. }
  90. ----
  91. After creating the `remote-replication` role on each cluster, use the
  92. <<security-api-put-user,create or update users API>> to create a user on
  93. the local cluster cluster and assign the `remote-replication` role. For
  94. example, the following request assigns the `remote-replication` role to a user
  95. named `cross-cluster-user`:
  96. [source,console]
  97. ----
  98. POST /_security/user/cross-cluster-user
  99. {
  100. "password" : "l0ng-r4nd0m-p@ssw0rd",
  101. "roles" : [ "remote-replication" ]
  102. }
  103. ----
  104. // TEST[continued]
  105. NOTE: You only need to create this user on the *local* cluster.
  106. //end::configure-ccr-privileges[]
  107. You can then <<ccr-getting-started-tutorial,configure {ccr}>> to replicate your
  108. data across datacenters.
  109. [[remote-clusters-privileges-ccs]]
  110. ==== Configure privileges for {ccs}
  111. The {ccs} user requires different cluster and index privileges on the remote
  112. cluster and local cluster. The following requests create separate roles on the
  113. local and remote clusters, and then create a user with the required roles.
  114. [discrete]
  115. ===== Remote cluster
  116. On the remote cluster, the {ccs} role requires the `read` and
  117. `read_cross_cluster` privileges for the target indices.
  118. NOTE: If requests are authenticated with an <<security-api-create-api-key, API key>>, the API key
  119. requires the above privileges on the **local** cluster, instead of the remote.
  120. NOTE: If requests are issued <<run-as-privilege,on behalf of other users>>,
  121. then the authenticating user must have the `run_as` privilege on the remote
  122. cluster.
  123. The following request creates a `remote-search` role on the remote cluster:
  124. [source,console]
  125. ----
  126. POST /_security/role/remote-search
  127. {
  128. "indices": [
  129. {
  130. "names": [
  131. "target-indices"
  132. ],
  133. "privileges": [
  134. "read",
  135. "read_cross_cluster"
  136. ]
  137. }
  138. ]
  139. }
  140. ----
  141. ////
  142. [source,console]
  143. ----
  144. DELETE /_security/role/remote-search
  145. ----
  146. // TEST[continued]
  147. ////
  148. [discrete]
  149. ===== Local cluster
  150. On the local cluster, which is the cluster used to initiate cross cluster
  151. search, a user only needs the `remote-search` role. The role privileges can be
  152. empty.
  153. The following request creates a `remote-search` role on the local cluster:
  154. [source,console]
  155. ----
  156. POST /_security/role/remote-search
  157. {}
  158. ----
  159. After creating the `remote-search` role on each cluster, use the
  160. <<security-api-put-user,create or update users API>> to create a user on the
  161. local cluster and assign the `remote-search` role. For example, the following
  162. request assigns the `remote-search` role to a user named `cross-search-user`:
  163. [source,console]
  164. ----
  165. POST /_security/user/cross-search-user
  166. {
  167. "password" : "l0ng-r4nd0m-p@ssw0rd",
  168. "roles" : [ "remote-search" ]
  169. }
  170. ----
  171. // TEST[continued]
  172. NOTE: You only need to create this user on the *local* cluster.
  173. Users with the `remote-search` role can then
  174. <<modules-cross-cluster-search,search across clusters>>.
  175. [[clusters-privileges-ccs-kibana-cert]]
  176. ==== Configure privileges for {ccs} and {kib}
  177. When using {kib} to search across multiple clusters, a two-step authorization
  178. process determines whether or not the user can access data streams and indices
  179. on a remote cluster:
  180. * First, the local cluster determines if the user is authorized to access remote
  181. clusters. The local cluster is the cluster that {kib} is connected to.
  182. * If the user is authorized, the remote cluster then determines if the user has
  183. access to the specified data streams and indices.
  184. To grant {kib} users access to remote clusters, assign them a local role
  185. with read privileges to indices on the remote clusters. You specify data streams
  186. and indices in a remote cluster as `<remote_cluster_name>:<target>`.
  187. To grant users read access on the remote data streams and indices, you must
  188. create a matching role on the remote clusters that grants the
  189. `read_cross_cluster` privilege with access to the appropriate data streams and
  190. indices.
  191. For example, you might be actively indexing {ls} data on a local cluster and
  192. and periodically offload older time-based indices to an archive on your remote
  193. cluster. You want to search across both clusters, so you must enable {kib}
  194. users on both clusters.
  195. [discrete]
  196. ===== Local cluster
  197. On the local cluster, create a `logstash-reader` role that grants
  198. `read` and `view_index_metadata` privileges on the local `logstash-*` indices.
  199. NOTE: If you configure the local cluster as another remote in {es}, the
  200. `logstash-reader` role on your local cluster also needs to grant the
  201. `read_cross_cluster` privilege.
  202. [source,console]
  203. ----
  204. POST /_security/role/logstash-reader
  205. {
  206. "indices": [
  207. {
  208. "names": [
  209. "logstash-*"
  210. ],
  211. "privileges": [
  212. "read",
  213. "view_index_metadata"
  214. ]
  215. }
  216. ]
  217. }
  218. ----
  219. Assign your {kib} users a role that grants
  220. {kibana-ref}/xpack-security-authorization.html[access to {kib}], as well as your
  221. `logstash_reader` role. For example, the following request creates the
  222. `cross-cluster-kibana` user and assigns the `kibana-access` and
  223. `logstash-reader` roles.
  224. [source,console]
  225. ----
  226. PUT /_security/user/cross-cluster-kibana
  227. {
  228. "password" : "l0ng-r4nd0m-p@ssw0rd",
  229. "roles" : [
  230. "logstash-reader",
  231. "kibana-access"
  232. ]
  233. }
  234. ----
  235. [discrete]
  236. ===== Remote cluster
  237. On the remote cluster, create a `logstash-reader` role that grants the
  238. `read_cross_cluster` privilege and `read` and `view_index_metadata` privileges
  239. for the `logstash-*` indices.
  240. [source,console]
  241. ----
  242. POST /_security/role/logstash-reader
  243. {
  244. "indices": [
  245. {
  246. "names": [
  247. "logstash-*"
  248. ],
  249. "privileges": [
  250. "read_cross_cluster",
  251. "read",
  252. "view_index_metadata"
  253. ]
  254. }
  255. ]
  256. }
  257. ----