Enable TLS on the transport layer

(Sachin) #1

Hi Team,

I was wondering whether ReadonlyREST plugin supports encrypted node to node communication on the transport port (transport.tcp.port) . I’ve gone through below discussion, but looks like it’s outdated.

If RoR supports encrypted node to node communication, Can this property transport.type be used for enabling encryption ?


(Askids) #2

No. ROR won’t be adding that support. Use Searchguard SSL to enable SSL on transport port. You can use a single certificate, include all nodes on that certificate, enable host verification on the SG-SSL configuration. Essentially, this will make sure that only ES nodes can use transport port for communication. For all others, the port will not be accessible, unless connecting locally from those nodes and they will need to use the certificates.

Downside of this approach compared to using separate certificates, is that if you want to expand your cluster, you will need to apply new certificate which includes new host names. If you plan to expand, you can go the standard route that SG recommends.

ES no longer recommends using transport port for any data access. So all you need to do is ensure that port is not accessible for others. Hope this helps.


(Ld57) #3


an another way to secure transport layer between cluster members is to use stunnel, with authentication client/server using certificates for each node.

if needed I can help on configuring that.

(Simone Scarduzio) #4

By the way, for the records: last week I experimented on my laptop and tried to use SG SSL, and it’s not as straight forward as it used to be.

It kept on failing with:

org.elasticsearch.bootstrap.StartupException: java.lang.IllegalArgumentException: Cannot have more than one plugin implementing a REST wrapper

I made some experiment, turns out the usual searchguard.ssl.http.enabled: 'false' is not enough anymore.
Nowadays SG needs a tiny code patch (comment out onIndexModule, and getRestHandlerWrapper methods) in order to coexist with ROR.

Also, I noticed SG SSL (Apache 2.0 licensed) has a binary dependency to the main SG project (visible source, but non-free license). So it’s exponentially more unclear if a non SG-licensed user can legally use SG SSL even if it’s Apache 2.0.

edit: @jochenkressin (the author of SG) actually said this it’s legal (as of Apache 2.0 license) to use SG SSL for free alongside ROR, if you have inter-node SSL as a requirement.

In the meanwhile, a customer reported they implemented way faster than SG inter-node SSL encryption in Elasticsearch using Kubernetes using the weave net plugin. Never tried personally though, needs investigation.

(Jochen Kressin) #5

Just to clarify a bit here:

The Search Guard SSL plugin does not have any dependency on the main Search Guard project.

The main Search Guard repository houses the Community Edition and is fully licensed under Apache2:


The only repository that is under a commercial license is the Enterprise Modules repository:


The latter is only relevant if you want to use the Enterprise and or Compliance features. Neither SG-SLL nor SG need the Enterprise modules to run.

(Sachin) #6

Thank you all for the detailed response. Planning not to use Transport port for data access and will configure transport port behind the firewall.