mirror of
https://github.com/elastic/elasticsearch.git
synced 2025-06-28 01:22:26 -04:00
bd873698bc
We were depending on the BouncyCastle FIPS own mechanics to set
itself in approved only mode since we run with the Security
Manager enabled. The check during startup seems to happen before we
set our restrictive SecurityManager though in
org.elasticsearch.bootstrap.Elasticsearch , and this means that
BCFIPS would not be in approved only mode, unless explicitly
configured so.
This commit sets the appropriate JVM property to explicitly set
BCFIPS in approved only mode in CI and adds tests to ensure that we
will be running with BCFIPS in approved only mode when we expect to.
It also sets xpack.security.fips_mode.enabled to true for all test clusters
used in fips mode and sets the distribution to the default one. It adds a
password to the elasticsearch keystore for all test clusters that run in fips
mode.
Moreover, it changes a few unit tests where we would use bcrypt even in
FIPS 140 mode. These would still pass since we are bundling our own
bcrypt implementation, but are now changed to use FIPS 140 approved
algorithms instead for better coverage.
It also addresses a number of tests that would fail in approved only mode
Mainly:
Tests that use PBKDF2 with a password less than 112 bits (14char). We
elected to change the passwords used everywhere to be at least 14
characters long instead of mandating
the use of pbkdf2_stretch because both pbkdf2 and
pbkdf2_stretch are supported and allowed in fips mode and it makes sense
to test with both. We could possibly figure out the password algorithm used
for each test and adjust password length accordingly only for pbkdf2 but
there is little value in that. It's good practice to use strong passwords so if
our docs and tests use longer passwords, then it's for the best. The approach
is brittle as there is no guarantee that the next test that will be added won't
use a short password, so we add some testing documentation too.
This leaves us with a possible coverage gap since we do support passwords
as short as 6 characters but we only test with > 14 chars but the
validation itself was not tested even before. Tests can be added in a followup,
outside of fips related context.
Tests that use a PKCS12 keystore and were not already muted.
Tests that depend on running test clusters with a basic license or
using the OSS distribution as FIPS 140 support is not available in
neither of these.
Finally, it adds some information around FIPS 140 testing in our testing
documentation reference so that developers can hopefully keep in
mind fips 140 related intricacies when writing/changing docs.
157 lines
4.6 KiB
Text
157 lines
4.6 KiB
Text
[[cross-cluster-configuring]]
|
|
=== {ccs-cap} and security
|
|
|
|
<<modules-cross-cluster-search,{ccs-cap}>> enables
|
|
federated search across multiple clusters. When using cross cluster search
|
|
with secured clusters, all clusters must have the {es} {security-features}
|
|
enabled.
|
|
|
|
The local cluster (the cluster used to initiate cross cluster search) must be
|
|
allowed to connect to the remote clusters, which means that the CA used to
|
|
sign the SSL/TLS key of the local cluster must be trusted by the remote
|
|
clusters.
|
|
|
|
User authentication is performed on the local cluster and the user and user's
|
|
roles are passed to the remote clusters. A remote cluster checks the user's
|
|
roles against its local role definitions to determine which indices the user
|
|
is allowed to access.
|
|
|
|
|
|
[WARNING]
|
|
This feature was added as Beta in {es} `v5.3` with further improvements made in
|
|
5.4 and 5.5. It requires gateway eligible nodes to be on `v5.5` onwards.
|
|
|
|
To use cross cluster search with secured clusters:
|
|
|
|
* Enable the {es} {security-features} on every node in each connected cluster.
|
|
For more information about the `xpack.security.enabled` setting, see
|
|
<<security-settings>>.
|
|
|
|
* Enable encryption globally. To encrypt communications, you must enable
|
|
<<ssl-tls,enable SSL/TLS>> on every node.
|
|
|
|
* Enable a trust relationship between the cluster used for performing cross
|
|
cluster search (the local cluster) and all remote clusters. This can be done
|
|
either by:
|
|
+
|
|
** Using the same certificate authority to generate certificates for all
|
|
connected clusters, or
|
|
** Adding the CA certificate from the local cluster as a trusted CA in
|
|
each remote cluster (see <<transport-tls-ssl-settings>>).
|
|
|
|
|
|
* On the local cluster, ensure that users are assigned to (at least) one role
|
|
that exists on the remote clusters. On the remote clusters, use that role
|
|
to define which indices the user may access. (See <<authorization>>).
|
|
|
|
* Configure the local cluster to connect to remote clusters as described
|
|
in <<configuring-remote-clusters>>.
|
|
For example, the following configuration adds two remote clusters
|
|
to the local cluster:
|
|
+
|
|
--
|
|
[source,console]
|
|
-----------------------------------------------------------
|
|
PUT _cluster/settings
|
|
{
|
|
"persistent": {
|
|
"cluster": {
|
|
"remote": {
|
|
"one": {
|
|
"seeds": [ "10.0.1.1:9300" ]
|
|
},
|
|
"two": {
|
|
"seeds": [ "10.0.2.1:9300" ]
|
|
}
|
|
}
|
|
}
|
|
}
|
|
}
|
|
-----------------------------------------------------------
|
|
--
|
|
|
|
|
|
|
|
[[cross-cluster-configuring-example]]
|
|
==== Example configuration of cross cluster search
|
|
|
|
In the following example, we will configure the user `alice` to have permissions
|
|
to search any data stream or index starting with `logs-` in cluster `two` from
|
|
cluster `one`.
|
|
|
|
First, enable cluster `one` to perform cross cluster search on remote cluster
|
|
`two` by running the following request as the superuser on cluster `one`:
|
|
|
|
[source,console]
|
|
-----------------------------------------------------------
|
|
PUT _cluster/settings
|
|
{
|
|
"persistent": {
|
|
"cluster.remote.two.seeds": [ "10.0.2.1:9300" ]
|
|
}
|
|
}
|
|
-----------------------------------------------------------
|
|
|
|
Next, set up a role called `cluster_two_logs` on both cluster `one` and
|
|
cluster `two`.
|
|
|
|
On cluster `one`, this role does not need any special privileges:
|
|
|
|
[source,console]
|
|
-----------------------------------------------------------
|
|
POST /_security/role/cluster_two_logs
|
|
{
|
|
}
|
|
-----------------------------------------------------------
|
|
|
|
On cluster `two`, this role allows the user to query local indices called
|
|
`logs-` from a remote cluster:
|
|
|
|
[source,console]
|
|
-----------------------------------------------------------
|
|
POST /_security/role/cluster_two_logs
|
|
{
|
|
"cluster": [],
|
|
"indices": [
|
|
{
|
|
"names": [
|
|
"logs-*"
|
|
],
|
|
"privileges": [
|
|
"read",
|
|
"read_cross_cluster"
|
|
]
|
|
}
|
|
]
|
|
}
|
|
-----------------------------------------------------------
|
|
|
|
Finally, create a user on cluster `one` and apply the `cluster_two_logs` role:
|
|
|
|
[source,console]
|
|
-----------------------------------------------------------
|
|
POST /_security/user/alice
|
|
{
|
|
"password" : "somepasswordhere",
|
|
"roles" : [ "cluster_two_logs" ],
|
|
"full_name" : "Alice",
|
|
"email" : "alice@example.com",
|
|
"enabled": true
|
|
}
|
|
-----------------------------------------------------------
|
|
|
|
With all of the above setup, the user `alice` is able to search indices in
|
|
cluster `two` as follows:
|
|
|
|
[source,console]
|
|
-----------------------------------------------------------
|
|
GET two:logs-2017.04/_search
|
|
{
|
|
"query": {
|
|
"match_all": {}
|
|
}
|
|
}
|
|
-----------------------------------------------------------
|
|
// TEST[skip:todo]
|
|
|
|
include::cross-cluster-kibana.asciidoc[]
|