RoR and Cross-Cluster Search

#1

Hi,
Your documentation explains, quite well, why RoR does not cover the elasticsearch transport interface (9300).

However, cross cluster search is a very useful feature which links clusters via the transport interface. Do you have plans to address this in some way?

Thx
D

#2

Actually the cross cluster search should work, as long as you have ROR installed in every node of the two (or more) clusters. The ACL applied will be the one defined in the cluster where the request is received.

You can use the indices rule with cross cluster semantics like this:

indices: ["clusterX:remote_index", "local_index1"]

Wildcard included. Have a try.

#3

But CCS connects clusters via the transport, rather than REST, interface? RoR wouldn’t see the traffic…

#4

Will you need to look at this as a feature request @sscarduzio?

#5

@cresta the incoming request is rejected, accepted, or patched on the fly by ROR inside the incoming node. In the case it gets patched (i.e. ROR removed forbidden indices from the request), the request is good to go to whatever cluster via whatever protocol and return the response to the user agent. I know in X-Pack this works entirely differently, but this is actually a point of strength in ROR.

For FLS/DLS where we would add the allowed fields or the filter string to some ROR-custom request headers (which ES will carry on through the transport protocol) and if the destination nodes have ROR installed, the FLS/DLS will be applied.

I think you should test this.

#6

I think we’re talking at crossed purposes here. I believe, you’re talking about a search request that references remote indices. If I’m misinterpreting your response, I apologise.

Let me try to be more explicit with a scenario that should make my question clearer:

Local Cluster:

  • Does not have RoR installed
  • Does have cross-cluster search enabled with seed nodes specified for Remote Cluster
  • Kibana: uses Local Cluster to query Remote Cluster

Remote Cluster:

  • Does have RoR installed
  • No local Kibana instances
  • For the sake of argument no local searches, and they’re blocked by RoR anyway

For kibana to search the indices on Remote Cluster, Local Cluster needs to establish a transport connection and register the remote indices etc. This is all good.

However, were someone to wish to circumvent RoR then could create a single node elasticsearch cluster, configure CCS with details of the RoR enabled cluster and then search those indices even when the RoR rules do not permit it.

#7

So basically you would like to have a mechanism to allow connections on the transport layer from your remote cluster, but not from anybody else. Right?

#8

I’d like to be able to ensure that search activity via the transport layer aligns with the ror policies on port 9200. It’s unauthorised access that concerns me more than anything.

#9

One of the neatest ways to encrypt and authenticate a machine-to-machine connection is to use SSL PKI authentication. You distribute the certs at deploy time, and then the only way to connect to the port 9300 is in SSL, and the client has to have that particular certificate.

The only issue with this is that at the moment you can’t enable SSL for remote cluster connection requests only. Also the internal inter-node traffic in the local cluster need to use it.

ROR has support for inter-node SSL. This is how it’s configured:

readonlyrest:
    ssl:
      # put the keystore in the same dir with elasticsearch.yml 
      keystore_file: "keystore.jks"
      keystore_pass: readonlyrest
      key_pass: readonlyrest
      allowed_protocols: [TLSv1.2]
      allowed_ciphers: [TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256]

    internode_ssl:
      # put the keystore in the same dir with elasticsearch.yml 
      keystore_file: "internode_keystore.jks"
      keystore_pass: readonlyrest
      key_pass: readonlyrest
      allowed_protocols: [TLSv1.2]
      verify: true # <--- You want to enable this in prod!
      allowed_ciphers: [TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256]

In your case, you should share the same keystore on all the nodes of both the clusters.
What do you think? Can this satisfy your requirement?