Discovery zen ping and password protected ES

Elastic Stack Elasticsearch
1

Any idea how does this work with password protected ES nodes?
I'm just about to test it but I need to make backups first :wink:

2

That's a very vague question about a fairly in depth topic.

The short answer is that all internode communication, including discovery pings, use the transport port (9300) not the http port (9200), and the security model for the transport port is not the same as the http port.

Transport port doesn't require passwords, it is secured using TLS.

1 Like
3

Ok, thanks, but how does the ping work exactly? I thought this also has to be secured, so no other rogue node could advertise itself as a part of a cluster.

4

it is secured using TLS.

by default?

5

It will ping for other nodes, then if it gets a response it'll validate that using TLS.

This is a good example of how it all works - https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_7.1.0/com.ibm.mq.doc/sy10660_.htm

6

Yes, in Elasticsearch 6.x, TLS is required for internode communication.

I'm happy to explain how it all works, but a complete & detailed answer would take several pages of explanation and diagrams.
If you've read through our docs, and have specific questions then please ask and I'll do my best to answer them, but I can't write an ad-hoc whitepaper on cluster security models.

7

@warkolm pointed out that this anwers skips some details that might be helpful.

My assumption when you talk about "password proected ES" is that you're referring to using our Elastic Stack security features. In that context, if you have security enabled on a production (non-trial) license, then TLS is required.

In our security model:

  • For the HTTP (Rest) interface, passwords are the default authentication mechanism (although we support other options like TLS certs ("pki"), SAML and Kerberos).
  • For transport (internode) communication, including pings, we secure the cluster membership via TLS certs.

Those are pretty much tied together - you can't have one without the other (*).

(*) Technically, you can enable anonymous access to some actions which is a bit like having TLS without having passwords, but it's not exactly the same.

1 Like
8

Thanks for the explanation, but my question was about the communication on port 9300. Here is a list of detailed queries:

  • On port 9300, is the communication encrypted by default or not?
  • If not, then how can I turn it on
  • How can I manage encryption on port 9300 (assuming positive answers to the queries above) via the yml files? In terms of login, password, location of the crt files etc
  • What is exactly happening on port 9300. I know I can use wireshark etc, but can I find any technical documentation or more details about the communication on port 9300?

Thanks.

9

See: https://www.elastic.co/guide/en/elastic-stack-overview/6.4/encrypting-communications.html

10

Checked it. No technical details and no information about 9300 communications

11

Hi @wheelq, Did you check the next chapters following the links in the documentation, say
https://www.elastic.co/guide/en/elastic-stack-overview/6.4/ssl-tls.html
https://www.elastic.co/guide/en/elasticsearch/reference/6.4/configuring-tls.html#tls-transport
Hope this helps.

12

Yes, I have checked. All of those links redirect to other links which end up with redirection to the original links. Just walking in circles, and being pushed to use x-pack and provide information how to configure tls...which again, was not my question.

I am after technical documentation, information, what is happening on port 9300 (structure of the packets, communication type) without using x-pack.

If there is no such document than I'll investigate this myself

13

There is no such documentation. The details of the protocol that Elasticsearch uses for inter-node communication is deliberately undocumented as it varies, possibly wildly, from version to version. You can read the source code of a particular version if you're interested in that version's protocol (see, for instance, TcpTransport#buildMessage in recent versions) but be warned that it may change in future.

I do not understand how this pertains to your original question on password protection. There is no password-protection functionality in this protocol. To ensure integrity or authenticity of inter-node communication, you should use the security features provided by X-pack.

1 Like
14

thanks

15

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