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

56 lines
2.5 KiB
Groovy
Raw Normal View History

import org.elasticsearch.gradle.info.BuildParams
apply plugin: 'elasticsearch.testclusters'
apply plugin: 'elasticsearch.standalone-rest-test'
apply plugin: 'elasticsearch.rest-test'
7.x - Create plugin for yamlTest task (#56841) (#59090) This commit creates a new Gradle plugin to provide a separate task name and source set for running YAML based REST tests. The only project converted to use the new plugin in this PR is distribution/archives/integ-test-zip. For which the testing has been moved to :rest-api-spec since it makes the most sense and it avoids a small but awkward change to the distribution plugin. The remaining cases in modules, plugins, and x-pack will be handled in followups. This plugin is distinctly different from the plugin introduced in #55896 since the YAML REST tests are intended to be black box tests over HTTP. As such they should not (by default) have access to the classpath for that which they are testing. The YAML based REST tests will be moved to separate source sets (yamlRestTest). The which source is the target for the test resources is dependent on if this new plugin is applied. If it is not applied, it will default to the test source set. Further, this introduces a breaking change for plugin developers that use the YAML testing framework. They will now need to either use the new source set and matching task, or configure the rest resources to use the old "test" source set that matches the old integTest task. (The former should be preferred). As part of this change (which is also breaking for plugin developers) the rest resources plugin has been removed from the build plugin and now requires either explicit application or application via the new YAML REST test plugin. Plugin developers should be able to fix the breaking changes to the YAML tests by adding apply plugin: 'elasticsearch.yaml-rest-test' and moving the YAML tests under a yamlRestTest folder (instead of test)
2020-07-06 15:16:26 -04:00
apply plugin: 'elasticsearch.rest-resources'
dependencies {
testImplementation project(path: xpackModule('core'), configuration: 'default')
testImplementation project(path: xpackModule('security'), configuration: 'testArtifacts')
testImplementation project(path: xpackModule('core'), configuration: 'testArtifacts')
testImplementation project(path: ':modules:reindex')
}
forbiddenPatterns {
exclude '**/*.key'
exclude '**/*.pem'
exclude '**/*.p12'
exclude '**/*.jks'
}
File caFile = project.file('src/test/resources/ssl/ca.p12')
testClusters.integTest {
testDistribution = 'DEFAULT'
// Whitelist reindexing from the local node so we can test it.
extraConfigFile 'http.key', file('src/test/resources/ssl/http.key')
extraConfigFile 'http.crt', file('src/test/resources/ssl/http.crt')
extraConfigFile 'ca.p12', caFile
setting 'reindex.remote.whitelist', '127.0.0.1:*'
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
if (BuildParams.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', file('roles.yml')
user username: "test_admin", password: 'x-pack-test-password', role: "superuser"
user username: "powerful_user", password: 'x-pack-test-password', role: "superuser"
user username: "minimal_user", password: 'x-pack-test-password', role: "minimal"
user username: "minimal_with_task_user", password: 'x-pack-test-password', role: "minimal_with_task"
user username: "readonly_user", password: 'x-pack-test-password', role: "readonly"
user username: "dest_only_user", password: 'x-pack-test-password', role: "dest_only"
user username: "can_not_see_hidden_docs_user", password: 'x-pack-test-password', role: "can_not_see_hidden_docs"
user username: "can_not_see_hidden_fields_user", password: 'x-pack-test-password', role: "can_not_see_hidden_fields"
}