honeymoose
/
OpenSearch
mirror of https://github.com/honeymoose/OpenSearch.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
OpenSearch/x-pack/plugin/ccr/qa/security/leader-roles.yml

10 lines
206 B
YAML
Raw Normal View History

[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:
[CCR] Validate index privileges prior to following an index (#33758) Prior to following an index in the follow API, check whether current user has sufficient privileges in the leader cluster to read and monitor the leader index. Also check this in the create and follow API prior to creating the follow index. Also introduced READ_CCR cluster privilege that include the minimal cluster level actions that are required for ccr in the leader cluster. So a user can follow indices in a cluster, but not use the ccr admin APIs. Closes #33553 Co-authored-by: Jason Tedor <jason@tedor.me>
2018-09-28 11:51:23 -04:00
- read_ccr
[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
indices:
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: [ 'allowed-index', 'clean-leader', 'forget-leader', '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
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
- manage_leader_index