How to prevent other nodes from joining my cluster?

Elastic Stack Elasticsearch
1

How can I prevent other elasticsearch nodes from joining my cluster. Let's say I initiate a single node elastic cluster like this:

(Notice I am using letsencrypt ssl certificates)

cluster.initial_master_nodes: ["node1"]
cluster.name: my-application
node.name: node1
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch
network.host: node1.example.com
http.port: 9200
xpack.security.enabled: true
xpack.security.enrollment.enabled: true
xpack.security.http.ssl:
  enabled: true
  key: letsencrypt/certs/node1.example.com/privkey.pem
  certificate: letsencrypt/certs/node1.example.com/cert.pem
xpack.security.transport.ssl:
  enabled: true
  verification_mode: certificate
  key: letsencrypt/certs/node1.example.com/privkey.pem
  certificate: letsencrypt/certs/node1.example.com/cert.pem
http.host: 0.0.0.0

I find that any one can join my cluster by simply starting up a new elastic instance with this elasticsearch.yml file:

discovery.seed_hosts: ["node1.evermight.com"]
cluster.name: my-application
node.name: node2
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch
network.host: node2.example.com
http.port: 9200
xpack.security.enabled: true
xpack.security.enrollment.enabled: true
xpack.security.http.ssl:
  enabled: true
  key: letsencrypt/certs/node2.example.com/privkey.pem
  certificate: letsencrypt/certs/node2.example.com/cert.pem
xpack.security.transport.ssl:
  enabled: true
  verification_mode: certificate
  key: letsencrypt/certs/node2.example.com/privkey.pem
  certificate: letsencrypt/certs/node2.example.com/cert.pem
http.host: 0.0.0.0

It seems like node2 doesn't need to do any kind of authentication or verification with node1. So for now, I'm only using a firewall to whitelist IP addresses of machines that I will allow to join my elastic cluster.

Is there another way to prevent other nodes from joining my elasticsearch cluster?

Additional Notes: I noticed that if node1 uses autogenerated self signed certificates, then no other nodes can join the cluster. The only way for other nodes to join the cluster would be for the other nodes to first run ./bin/elasticsearch-reconfigure-node --enrollment-token <token issued by node1>.

Which if were to guess...my guess is that running ./bin/elasticsearch-reconfigure-node on node2 causes node2 to some way to download intermediate ssl certificates from node1. Therefore, node1 and node2 only trust each other based the trust of intermediate ssl certificate authorities.

And how it relates to my above situation...by using Let's Encrypt SSL for both node 1 and node 2, both certificates are already verified and have trusted CA, so node 1 will automatically allow node 2 to join.

Is it something like that?

2

You wouldn’t normally use Lets Encrypt certs for xpack.security.transport.ssl because that means you have to trust the Lets Encrypt root certs, which means that essentially anyone can get a certificate which would permit them to add a node to your cluster. Instead if you don’t want to use the enrollment mechanism you would create your own CA so that you can control exactly which certificates are issued and therefore exactly which nodes can join the cluster.

See Security settings in Elasticsearch | Elasticsearch Guide [8.6] | Elastic, particularly the xpack.security.transport.ssl.certificate_authorities and/or xpack.security.transport.ssl.truststore.path settings.

4 Likes
3

Elasticsearch nodes communicate with each other using the transport interface and the transport certificates, in theory if you have a public CA like Let's encrypt creating your transport certificates and your transport interface is public accessible, a rogue node would be able to join your cluster, didn't test it, but it seems possible.

Besides using a Firewall to whitelist IP addresses, you can also do the same thing in Elasticsearch using IP Filtering, you can allow or deny ip addresses that can or can not access your Elasticsearch.

Also, pay attention to this note in the documentation:

Elasticsearch installations are not designed to be publicly accessible over the Internet. IP Filtering and the other capabilities of the Elasticsearch security features do not change this condition.

But even on a private network you should limit the IP addresses that can access the transport interface, you can also bind the transport interface to a different IP address if available.

1 Like
4

OK, this makes sense and is a valuable lesson on when not to use public CAs. Thank you

@leandrojmp thanks for the note about elasticsearch installations not meant to be publicly accessible.

5

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.