Web Portocols and Ports used by Elasticsearch

Hi,

I need to know all the protocols ( http, tcp.. etc) Elasticsearch uses for

  1. client-server communication (indexing, querying.. etc)
  2. Inter-communication between primary and replica shards ( For leader election, recovery, backup.. etc)
    Or for any communication ES utilizes.
    I need this information for Network security ( which ports to secure ). Could someone help me on this?
1 Like

Welcome.

Ports used are 9200 and 9300 by default.

Thank you dadoonet.
Are these the only two ports used?
What are these ports used for and what is the protocol it is using ( http/tcp )?

Yes.

9200 for REST Http calls
9300 is the binary port for node to node communication

Hi dadoonet,

Thanks for the helping me with the answers.
Is it possible to configure 9300 to take http protocol request instead of tcp?

You need 2 different ports.
You can also disable http (9200) if you wish. And add a coordinating node which has both 9200 and 9300 ports.

We are integrating ElasticSearch with Envoy ServiceMesh.
And want to use HTTP only everywhere instead of TCP.
Is it possible to do that?

As of now, we are aware of only 2 ports: 9200 (http) and 9300 (tcp).

  1. Is it possible to configure ES such that 9300 also becomes http?
  2. Are there any ports other than the above 2 that we need to be aware of ? (In Kibana, Master nodes or Data nodes)

Elasticsearch has its own "service mesh" (if you want to call it that) so I don't really see the need for an external one too. It's possible you can make this work but I don't think it will be easy. Or necessary.

No.

Can you please clarify what you mean by "own service mesh" ?

Sure. An Elasticsearch cluster is made up of lots of different components (a.k.a. services, although we don't really call them that) all running on the different nodes, but clients don't need to care about the details: you can send a HTTP request to any node in the cluster and it will work out how to split it up and route it to the right places to execute it and gather the responses back up again afterwards. It already handles all the things that you would typically ask of a service mesh: retries, failover, auto-discovery and self-healing, load-based routing, introspection and monitoring, coordination, security, etc. are all built in already.

That's not to say that you can't integrate it with a broader service ecosystem at the HTTP level, just that there's no need to bring the non-HTTP connections between nodes into that scope too.

1 Like

An external ServiceMesh can give features like request-specific custom-actions, access-control/security without the paid version and can even allow modifying request/responses from/to ES (although this last one is a little un-clean).

But regardless, just found out that Envoy kind of proxies can encrypt traffic at TCP level too. So we are good with TCP as well as HTTP ports for now.

Our free distribution includes access control - https://www.elastic.co/blog/security-for-elasticsearch-is-now-free

1 Like

Security is not really free.

As per https://www.elastic.co/subscriptions, security is free only for the basic version whose license says that it cannot be used for production.
https://github.com/elastic/elasticsearch/blob/7.0/licenses/ELASTIC-LICENSE.txt#L88

I don't think that line you link to means what you think. Otherwise no one would be using the software.

What exactly are you using Elasticsearch for? Not technically, from a business point of view. If you're re-distributing our software as part of a broader product, then you would be correct about restrictions, but you should really reach out to license@elastic.co to discuss this.

We are planning to use it for regular search kind of applications - like log-search, alternate key search, text-analysis etc.
But we are definitely not planning to redistribute ElasticSearch.

Just planning to install ES on a bunch of computes, index data and query it.

The data and queries can come from anywhere (private or public clients), no restrictions on it but will get sanitized enough so that it does not cause problems. ServiceMesh might help a bit with sanitization too (just thinking aloud on this one).

So from the above description, is it ok to use the basic license of ES for production environment since we are not re-distributing ES itself nor are we creating any derivative product from ES ?

Yes, it is.

The most important settings to make a successful connection are the Elasticsearch cluster name and the discovery mode. Graylog is able to discover the Elasticsearch nodes using multicast.

Any other suggestion ?