OpenSearch/x-pack/plugin/ccr/qa/security/follower-roles.yml

ccruser:
  cluster:
    - manage_ccr
  indices:
    - names: [ 'allowed-index', 'forget-follower', 'logs-eu-*' ]
      privileges:
        - monitor
        - read
        - write
        - manage_follow_index
    - names: [ 'clean-follower' ]
      privileges:
        - monitor
        - read
        - write
        - delete_index
        - manage_follow_index
[CCR] Make cross cluster replication work with security (#30239) If security is enabled today with ccr then the follow index api will fail with the fact that system user does not have privileges to use the shard changes api. The reason that system user is used is because the persistent tasks that keep the shards in sync runs in the background and the user that invokes the follow index api only start those background processes. I think it is better that the system user isn't used by the persistent tasks that keep shards in sync, but rather runs as the same user that invoked the follow index api and use the permissions that that user has. This is what this PR does, and this is done by keeping track of security headers inside the persistent task (similar to how rollup does this). This PR also adds a cluster ccr priviledge that allows a user to follow or unfollow an index. Finally if a user that wants to follow an index, it needs to have read and monitor privileges on the leader index and monitor and write privileges on the follow index. 2018-05-16 01:48:32 -04:00			`ccruser:`
			`cluster:`
			`- manage_ccr`
			`indices:`
Introduce forget follower API (#39718) This commit introduces the forget follower API. This API is needed in cases that unfollowing a following index fails to remove the shard history retention leases on the leader index. This can happen explicitly through user action, or implicitly through an index managed by ILM. When this occurs, history will be retained longer than necessary. While the retention lease will eventually expire, it can be expensive to allow history to persist for that long, and also prevent ILM from performing actions like shrink on the leader index. As such, we introduce an API to allow for manual removal of the shard history retention leases in this case. 2019-03-07 10:29:10 -05:00			`- names: [ 'allowed-index', 'forget-follower', 'logs-eu-*' ]`
[CCR] Make cross cluster replication work with security (#30239) If security is enabled today with ccr then the follow index api will fail with the fact that system user does not have privileges to use the shard changes api. The reason that system user is used is because the persistent tasks that keep the shards in sync runs in the background and the user that invokes the follow index api only start those background processes. I think it is better that the system user isn't used by the persistent tasks that keep shards in sync, but rather runs as the same user that invoked the follow index api and use the permissions that that user has. This is what this PR does, and this is done by keeping track of security headers inside the persistent task (similar to how rollup does this). This PR also adds a cluster ccr priviledge that allows a user to follow or unfollow an index. Finally if a user that wants to follow an index, it needs to have read and monitor privileges on the leader index and monitor and write privileges on the follow index. 2018-05-16 01:48:32 -04:00			`privileges:`
			`- monitor`
			`- read`
			`- write`
[CCR] Change unfollow API's privilege scheme. (#34175) Unfollow should be allowed / disallowed on a per index level instead of cluster level. Also renamed `create_follow_index` index privilege to `manage_follow_index` privilege and include unfollow and close APIs. 2018-10-06 07:38:28 -04:00			`- manage_follow_index`
Fix shard follow task cleaner under security (#52347) The shard follow task cleaner executes on behalf of the user to clean up a shard follow task after the follower index has been deleted. Otherwise, these persistent tasks are left laying around, and they fail to execute because the follower index has been deleted. In the face of security, attempts to complete these persistent tasks would fail. This is because these cleanups are executed under the system context (this makes sense, they are happening on behalf of the user after the user has executed an action) but the system role was never granted the permission for persistent task completion. This commit addresses this by adding this cluster privilege to the system role. 2020-02-16 17:21:28 -05:00			`- names: [ 'clean-follower' ]`
			`privileges:`
			`- monitor`
			`- read`
			`- write`
			`- delete_index`
			`- manage_follow_index`