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/build.gradle

52 lines
1.7 KiB
Groovy
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
import org.elasticsearch.gradle.test.RestIntegTestTask
Testclusters: convert ccr tests (#42313)
2019-05-29 09:16:04 -04:00
apply plugin: 'elasticsearch.testclusters'
[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
apply plugin: 'elasticsearch.standalone-test'
dependencies {
Apply 2-space indent to all gradle scripts (#49071) Backport of #48849. Update `.editorconfig` to make the Java settings the default for all files, and then apply a 2-space indent to all `*.gradle` files. Then reformat all the files.
2019-11-14 06:01:23 -05:00
testCompile project(path: xpackModule('core'), configuration: 'testArtifacts')
testCompile project(path: xpackModule('ccr'), configuration: 'runtime')
testCompile project(':x-pack:plugin:ccr:qa')
[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
}
Testclusters: convert ccr tests (#42313)
2019-05-29 09:16:04 -04:00
task 'leader-cluster'(type: RestIntegTestTask) {
Apply 2-space indent to all gradle scripts (#49071) Backport of #48849. Update `.editorconfig` to make the Java settings the default for all files, and then apply a 2-space indent to all `*.gradle` files. Then reformat all the files.
2019-11-14 06:01:23 -05:00
mustRunAfter(precommit)
runner {
systemProperty 'tests.target_cluster', 'leader'
}
[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
}
Testclusters: convert ccr tests (#42313)
2019-05-29 09:16:04 -04:00
testClusters.'leader-cluster' {
Apply 2-space indent to all gradle scripts (#49071) Backport of #48849. Update `.editorconfig` to make the Java settings the default for all files, and then apply a 2-space indent to all `*.gradle` files. Then reformat all the files.
2019-11-14 06:01:23 -05:00
testDistribution = 'DEFAULT'
setting 'xpack.license.self_generated.type', 'trial'
setting 'xpack.security.enabled', 'true'
extraConfigFile 'roles.yml', file('leader-roles.yml')
user username: "test_admin", role: "superuser"
user username: "test_ccr", role: "ccruser"
[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
}
Testclusters: convert ccr tests (#42313)
2019-05-29 09:16:04 -04:00
task 'follow-cluster'(type: RestIntegTestTask) {
Apply 2-space indent to all gradle scripts (#49071) Backport of #48849. Update `.editorconfig` to make the Java settings the default for all files, and then apply a 2-space indent to all `*.gradle` files. Then reformat all the files.
2019-11-14 06:01:23 -05:00
dependsOn 'leader-cluster'
runner {
useCluster testClusters.'leader-cluster'
systemProperty 'tests.target_cluster', 'follow'
nonInputProperties.systemProperty 'tests.leader_host', "${-> testClusters.'leader-cluster'.getAllHttpSocketURI().get(0)}"
}
[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
}
Testclusters: convert ccr tests (#42313)
2019-05-29 09:16:04 -04:00
testClusters.'follow-cluster' {
Apply 2-space indent to all gradle scripts (#49071) Backport of #48849. Update `.editorconfig` to make the Java settings the default for all files, and then apply a 2-space indent to all `*.gradle` files. Then reformat all the files.
2019-11-14 06:01:23 -05:00
testDistribution = 'DEFAULT'
setting 'cluster.remote.leader_cluster.seeds', {
"\"${testClusters.'leader-cluster'.getAllTransportPortURI().join(",")}\""
}
setting 'xpack.license.self_generated.type', 'trial'
setting 'xpack.security.enabled', 'true'
setting 'xpack.monitoring.collection.enabled', 'true'
extraConfigFile 'roles.yml', file('follower-roles.yml')
user username: "test_admin", role: "superuser"
user username: "test_ccr", role: "ccruser"
[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
}
Testclusters: convert ccr tests (#42313)
2019-05-29 09:16:04 -04:00
check.dependsOn 'follow-cluster'
[Backport] Replace usages RandomizedTestingTask with built-in Gradle Test (#40978) (#40993) * Replace usages RandomizedTestingTask with built-in Gradle Test (#40978) This commit replaces the existing RandomizedTestingTask and supporting code with Gradle's built-in JUnit support via the Test task type. Additionally, the previous workaround to disable all tasks named "test" and create new unit testing tasks named "unitTest" has been removed such that the "test" task now runs unit tests as per the normal Gradle Java plugin conventions. (cherry picked from commit 323f312bbc829a63056a79ebe45adced5099f6e6) * Fix forking JVM runner * Don't bump shadow plugin version
2019-04-09 14:52:50 -04:00
test.enabled = false // no unit tests for multi-cluster-search, only the rest integration test