Cross Cluster Search Support
Search Guard supports Cross Cluster Search out of the box, so there is nothing special to configure to make it work. Cross Cluster Search will replace Tribe nodes which are deprecated in Elasticsearch 6.x.
When accessing a
remote cluster from a
coordinating cluster via Cross Cluster Search:
- Search Guard authenticates the user on the coordinating cluster
- Search Guard fetches the users backend roles on the coordinating cluster
- The call including the authenticated user is forwarded to the remote cluster
- The user’s permissions are evaluated on the remote cluster
While it is possible to have different configurations regarding authentication and authorization on the remote and coordinating cluster, it is highly recommended to use the same settings on both.
Note: Tribe nodes are deprecated from Elasticsearch 6.x onwards.
Search Guard offers support for tribe nodes. A tribe node “acts as a federated client across multiple clusters” and is commonly used to retrieve information from multiple Elasticsearch clusters making it look like one combined cluster.
In order for tribe nodes to work with Search Guard, please make sure that the Search Guard index, i.e., the configuration settings, are identical on each particpiating cluster.
A tribe node will create a node client to connect to each configured cluster. If the participating clusters are secured via Search Guard, you need to configure the TLS settings on the transport layer for each. Think of the node client the tribe node as a regular node. This means that you need to create a keystore with a valid TLS certificate and the truststore containing the root CA and any intermediate certificate.
tribe: cl1: cluster.name: cl1 searchguard.ssl.transport.keystore_filepath: cluster-1-keystore.jks searchguard.ssl.transport.keystore_password: changeit searchguard.ssl.transport.truststore_filepath: truststore.jks searchguard.ssl.transport.truststore_password: changeit cl2: cluster.name: cl2 searchguard.ssl.transport.keystore_filepath: cluster-2-keystore.jks searchguard.ssl.transport.keystore_password: changeit searchguard.ssl.transport.truststore_filepath: truststore.jks searchguard.ssl.transport.truststore_password: changeit
As with regular nodes, you can, and probably should, create a certificate for each node separately, or use the same certificate on all nodes.
You can also use all the other configuration options for TLS, for example if OpenSSL should be used, if hostname verification should be enabled, or if the hostname should be resolved.
searchguard.ssl.transport.enable_openssl_if_available: true searchguard.ssl.transport.enforce_hostname_verification: <true|false> searchguard.ssl.transport.resolve_hostname: <true|false>
In addition to that, you also need to configure the TLS settings for the tribe node itself:
searchguard.ssl.transport.keystore_filepath: tribe-transport-keystore.jks searchguard.ssl.transport.keystore_password: changeit searchguard.ssl.transport.truststore_filepath: truststore.jks searchguard.ssl.transport.truststore_password: changeit searchguard.ssl.http.enabled: true searchguard.ssl.http.keystore_filepath: tribe-rest-keystore.jks searchguard.ssl.http.keystore_password: changeit searchguard.ssl.http.truststore_filepath: truststore.jks searchguard.ssl.http.truststore_password: changeit searchguard.ssl.http.clientauth_mode: NONE
As always, TLS on the REST layer is optional, but recommended.
As with a regular data nodes in your cluster, also specify the DN of the admin certificate(s) you want to use with sgadmin.
searchguard.authcz.admin_dn: - CN=kirk,OU=client,O=client,L=test, C=DE
If the tribe node starts up for the first time, it fetches the Search Guard index from one of the participating clusters.
If you make any changes, you need to refresh the Search Guard index on the tribe node as well. This might be automated in the future, but for now, use the
-rl switch to refresh manually:
./sgadmin.sh -ts truststore.jks -tspass ... -ks keystore.jks -kspass ... -p <tribe node port> -rl