OpenSearch/x-pack/qa/reindex-tests-with-security/build.gradle

69 lines
2.5 KiB
Groovy
Raw Normal View History

import org.elasticsearch.gradle.http.WaitForHttpResource
apply plugin: 'elasticsearch.standalone-rest-test'
apply plugin: 'elasticsearch.rest-test'
dependencies {
testCompile project(path: xpackModule('core'), configuration: 'default')
testCompile project(path: xpackModule('security'), configuration: 'testArtifacts')
testCompile project(path: xpackModule('core'), configuration: 'testArtifacts')
testCompile project(path: ':modules:reindex')
}
forbiddenPatterns {
exclude '**/*.key'
exclude '**/*.pem'
exclude '**/*.p12'
exclude '**/*.jks'
}
File caFile = project.file('src/test/resources/ssl/ca.p12')
integTestCluster {
// Whitelist reindexing from the local node so we can test it.
extraConfigFile 'http.key', project.projectDir.toPath().resolve('src/test/resources/ssl/http.key')
extraConfigFile 'http.crt', project.projectDir.toPath().resolve('src/test/resources/ssl/http.crt')
extraConfigFile 'ca.p12', caFile
setting 'reindex.remote.whitelist', '127.0.0.1:*'
setting 'xpack.ilm.enabled', 'false'
setting 'xpack.security.enabled', 'true'
setting 'xpack.ml.enabled', 'false'
setting 'xpack.license.self_generated.type', 'trial'
setting 'xpack.security.http.ssl.enabled', 'true'
setting 'xpack.security.http.ssl.certificate', 'http.crt'
setting 'xpack.security.http.ssl.key', 'http.key'
setting 'xpack.security.http.ssl.key_passphrase', 'http-password'
setting 'reindex.ssl.truststore.path', 'ca.p12'
setting 'reindex.ssl.truststore.password', 'password'
Update ciphers for TLSv1.3 and JDK11 if available (#42082) This commit updates the default ciphers and TLS protocols that are used when the runtime JDK supports them. New cipher support has been introduced in JDK 11 and 12 along with performance fixes for AES GCM. The ciphers are ordered with PFS ciphers being most preferred, then AEAD ciphers, and finally those with mainstream hardware support. When available stronger encryption is preferred for a given cipher. This is a backport of #41385 and #41808. There are known JDK bugs with TLSv1.3 that have been fixed in various versions. These are: 1. The JDK's bundled HttpsServer will endless loop under JDK11 and JDK 12.0 (Fixed in 12.0.1) based on the way the Apache HttpClient performs a close (half close). 2. In all versions of JDK 11 and 12, the HttpsServer will endless loop when certificates are not trusted or another handshake error occurs. An email has been sent to the openjdk security-dev list and #38646 is open to track this. 3. In JDK 11.0.2 and prior there is a race condition with session resumption that leads to handshake errors when multiple concurrent handshakes are going on between the same client and server. This bug does not appear when client authentication is in use. This is JDK-8213202, which was fixed in 11.0.3 and 12.0. 4. In JDK 11.0.2 and prior there is a bug where resumed TLS sessions do not retain peer certificate information. This is JDK-8212885. The way these issues are addressed is that the current java version is checked and used to determine the supported protocols for tests that provoke these issues.
2019-05-20 09:45:36 -04:00
// Workaround for JDK-8212885
rootProject.globalInfo.ready {
if (project.ext.runtimeJavaVersion.isJava12Compatible() == false) {
setting 'reindex.ssl.supported_protocols', 'TLSv1.2'
}
Update ciphers for TLSv1.3 and JDK11 if available (#42082) This commit updates the default ciphers and TLS protocols that are used when the runtime JDK supports them. New cipher support has been introduced in JDK 11 and 12 along with performance fixes for AES GCM. The ciphers are ordered with PFS ciphers being most preferred, then AEAD ciphers, and finally those with mainstream hardware support. When available stronger encryption is preferred for a given cipher. This is a backport of #41385 and #41808. There are known JDK bugs with TLSv1.3 that have been fixed in various versions. These are: 1. The JDK's bundled HttpsServer will endless loop under JDK11 and JDK 12.0 (Fixed in 12.0.1) based on the way the Apache HttpClient performs a close (half close). 2. In all versions of JDK 11 and 12, the HttpsServer will endless loop when certificates are not trusted or another handshake error occurs. An email has been sent to the openjdk security-dev list and #38646 is open to track this. 3. In JDK 11.0.2 and prior there is a race condition with session resumption that leads to handshake errors when multiple concurrent handshakes are going on between the same client and server. This bug does not appear when client authentication is in use. This is JDK-8213202, which was fixed in 11.0.3 and 12.0. 4. In JDK 11.0.2 and prior there is a bug where resumed TLS sessions do not retain peer certificate information. This is JDK-8212885. The way these issues are addressed is that the current java version is checked and used to determine the supported protocols for tests that provoke these issues.
2019-05-20 09:45:36 -04:00
}
extraConfigFile 'roles.yml', 'roles.yml'
[
test_admin: 'superuser',
powerful_user: 'superuser',
minimal_user: 'minimal',
Tasks: Only require task permissions (#35667) Right now using the `GET /_tasks/<taskid>` API and causing a task to opt in to saving its result after being completed requires permissions on the `.tasks` index. When we built this we thought that that was fine, but we've since moved towards not leaking details like "persisting task results after the task is completed is done by saving them into an index named `.tasks`." A more modern way of doing this would be to save the tasks into the index "under the hood" and to have APIs to manage the saved tasks. This is the first step down that road: it drops the requirement to have permissions to interact with the `.tasks` index when fetching task statuses and when persisting statuses beyond the lifetime of the task. In particular, this moves the concept of the "origin" of an action into a more prominent place in the Elasticsearch server. The origin of an action is ignored by the server, but the security plugin uses the origin to make requests on behalf of a user in such a way that the user need not have permissions to perform these actions. It *can* be made to be fairly precise. More specifically, we can create an internal user just for the tasks API that just has permission to interact with the `.tasks` index. This change doesn't do that, instead, it uses the ubiquitus "xpack" user which has most permissions because it is simpler. Adding the tasks user is something I'd like to get to in a follow up change. Instead, the majority of this change is about moving the "origin" concept from the security portion of x-pack into the server. This should allow any code to use the origin. To keep the change managable I've also opted to deprecate rather than remove the "origin" helpers in the security code. Removing them is almost entirely mechanical and I'd like to that in a follow up as well. Relates to #35573
2018-11-28 09:28:27 -05:00
minimal_with_task_user: 'minimal_with_task',
readonly_user: 'readonly',
dest_only_user: 'dest_only',
can_not_see_hidden_docs_user: 'can_not_see_hidden_docs',
can_not_see_hidden_fields_user: 'can_not_see_hidden_fields',
].each { String user, String role ->
setupCommand 'setupUser#' + user,
'bin/elasticsearch-users', 'useradd', user, '-p', 'x-pack-test-password', '-r', role
}
waitCondition = { node, ant ->
WaitForHttpResource http = new WaitForHttpResource("https", node.httpUri(), numNodes)
http.setTrustStoreFile(caFile)
http.setTrustStorePassword("password")
http.setUsername("test_admin")
http.setPassword("x-pack-test-password")
return http.wait(5000)
}
}