WARNING: Version 5.5 of the Elastic Stack has passed its EOL date.
This documentation is no longer being maintained and may be removed. If you are running this version, we strongly advise you to upgrade. For the latest information, see the current release documentation.
Cross Cluster Search and Security
editCross Cluster Search and Security
editCross Cluster Search enables federated search across multiple clusters. When using cross cluster search with secured clusters, all clusters must have X-Pack security 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.
This feature was added as Beta in Elasticsearch 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:
- Install X-Pack on every node in each connected cluster.
- Enable encryption globally. To encrypt communications, you must enable 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 settings).
-
Configure the local cluster to connect to remote clusters as described in Configuring Cross Cluster Search. For example, the following configuration adds two remote clusters to the local cluster:
PUT _cluster/settings { "persistent": { "search": { "remote": { "cluster_one": { "seeds": [ "10.0.1.1:9300" ] }, "cluster_two": { "seeds": [ "10.0.2.1:9300" ] } } } } }
- 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 Configuring Role-based Access Control).
-
On the local cluster, ensure that users have at least
read
access to the remote-index pattern. Our recommended practice is for the local cluster to grantread
for the*:*
pattern, and implement all index-level restrictions on the remote cluster. Attempts to impose tighter restrictions on the local cluster are likely to be ineffective and introduce unintended consequences. In future versions of X-Pack security, all users will automatically have access to cross cluster search and this step will no longer be required.
Example Configuration of Cross Cluster Search
editIn the following example, we will configure the user alice
to have permissions
to search any 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
:
PUT _cluster/settings { "persistent": { "search.remote.cluster_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 allows the user to query any indices on remote clusters:
POST /_xpack/security/role/cluster_two_logs { "indices": [ { "names": [ "*:*" ], "privileges": [ "read" ] } ] }
On cluster two
, this role allows the user to query local indices called
logs-
from a remote cluster:
POST /_xpack/security/role/cluster_two_logs { "cluster": [ "transport_client" ], "indices": [ { "names": [ "logs-*" ], "privileges": [ "read", "read_cross_cluster" ] } ] }
Finally, create a user on cluster one
and apply the cluster_two_logs
role:
POST /_xpack/security/user/alice { "password" : "somepassword", "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:
Cross Cluster Search and Kibana
editWhen Kibana is used to search across multiple clusters, a two-step authorization process determines whether or not the user can access indices on a remote cluster:
- First, the loal cluster determines if the user is authorized to access remote clusters. (The local cluster is the cluster Kibana is connected to.)
- If they are, the remote cluster then determines if the user has access to the specified indices.
To grant Kibana users access to remote clusters, assign them a local role
with read privileges to indices on the remote cluster(s). You specify remote
cluster indices as <remote_cluster_name>:<index_name>
.
To enable users to actually read the remote indices, you must create a matching
role on the remote cluster(s) that grants the read_cross_cluster
privilege
and access to the appropriate indices.
For example, if Kibana is connected to the cluster where you’re actively indexing Logstash data (your local cluster) and you’re periodically offloading older time-based indices to an archive cluster (your remote cluster) and you want to enable Kibana users to search both clusters:
-
On the local cluster, create a
logstash_reader
role that grantsread
andview_index_metadata
privileges on the locallogstash-*
indices as well as the remote Logstash indices,remote_cluster_name:logstash-*
.If you configure the local cluster as another remote in Elasticsearch, you can grant access to
*:logstash-*
to enable users to access both the local cluster and all of your remote clusters. In this case, thelogstash_reader
role on your local cluster also needs to grant theread_cross_cluster
privilege. -
Assign your Kibana users the
kibana_user
role and yourlogstash_reader
role. -
On the remote cluster, create a
logstash_reader
role that grants theread_cross_cluster
privilege andread
andview_index_metadata
privileges for thelogstash-*
indices.
Currently, Kibana shows an error when users without super user access
attempt to create cross-cluster index patterns; however, they are not blocked
from doing so. Granting users read access to *:*
on the local cluster will
eliminate these error messages. This does not grant access to everything on
a remote cluster, that is controlled by the corresponding role on the
remote cluster(s).