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 ?
Thanks,
Sachin
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.
Thanks!
Hi,
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.
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.
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:
https://github.com/floragunncom/search-guard/blob/master/LICENSE
The only repository that is under a commercial license is the Enterprise Modules repository:
https://github.com/floragunncom/search-guard-enterprise-modules.
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.
Thank you all for the detailed response. Planning not to use Transport port for data access and will configure transport port behind the firewall.
@sscarduzio did not want to open another thread for this. But I noticed that from 6.3.0 onwards, Searchguard has not released a standalone version of their SSL plugin. Below link says the following for Searchguard SSL
" not released as standalone plugin ". Are you aware if this is end of the road for using SG SSL along with ROR?
If we use their full plugin and try it run it in SSL only mode, we get the same error - “Cannot have more than one plugin implementing a REST wrapper”. Any suggestions?
I created inter-node SSL support, and it works using the latest 6.3.x onwards, but still haven’t had time to port it to older ES versions. Should prioritise this.
Thanks for the heads up @askids 
That is great news! I was actually helping out another team configure their setup. They were using 6.4.2 and ran into this issue. BTW, when is this feature expected to be made available?
After we encountered the issue, I went back and checked their documentation. Looks like in preparation for SG7, they have made this decision to merge the plugins and that is when they added an additional setting on elasticsearch.yml to allow running in SSL only mode.
I also did check their current SG code. When in SSL only mode, they are still registering few basic Rest handlers, but skipping many of the others that wont be used in SSL only mode. So I will probably also open an issue on their repo to see either if they can either skip registering the handler altogether in SSL only mode or at least provide another setting, that can be used to make it skip the registration part. First option may be easier to implement. But will need to see if they will agree to make this change.
As of now, I’m super busy with porting ROR to Kibana 6.5.x. Any help merging my internode SSL git branch is very much appreciated. Things to do:
I can review the PR and help, no pressure.
@sscarduzio unfortunately, I wont be of much help here. Had I been a Java developer, I would have definitely helped. Best help that I can provide from my end is be able to test it on windows environments (2K8/12), if you make any pre-release version available. But I will check, if I can get any volunteers from the other team 
BTW, the request to allow customization on the main Searchguard plugin has been declined by the author. They asked us to fork and start maintaining our own custom version or continue to maintain SG-SSL. So looks like using only ROR for both will be the way forward. Moreover, this is what we had requested long time back. So in oneway, its good for us as we will only have to deal with 1 plugin during upgrades.
Also, I feel that there is no need to backport this below 6.3.
When I get time, i will take a look at the branch and try to make some sense out of it. Based on our current usage of Searchguard-SSL, to some extent, we know what to expect from its replacement. So it may be possible to give some feedback on it. Lets see.
Hi Simone, do you have an ETA for this feature?
Yes I’d also like to know an ETA (unfortunately I don’t know java either to help out). But in the meantime, I’m not blocked by using earlier versions, so would someone (or @sscarduzio) mind just explaining how to use/enable this feature in ES 6.3+?
This feature is in a separate branch, other than master. Needs to be merged. Will probably have time to take this task in a week. Will probably take another week to finalise.
Sorry for the wait guys!
Why is that I don’t hear drumrolls 
Had it been on 5.x, I would have validated it immediately. But along with that, we have server upgrade going on from Windows 2008 to 2012/16 on most of the dev server my team uses. So I will need to request for some new certificates to test this out. So it my take some time, before I get to validate this.
In terms of TLS settings, this is what we currently use(except for ciphers) with SG.
searchguard.ssl.transport.keystore_type
searchguard.ssl.transport.keystore_filepath
searchguard.ssl.transport.keystore_alias
searchguard.ssl.transport.keystore_password
searchguard.ssl.transport.truststore_type
searchguard.ssl.transport.truststore_filepath
searchguard.ssl.transport.truststore_alias
searchguard.ssl.transport.truststore_password
searchguard.ssl.transport.enforce_hostname_verification
searchguard.ssl.transport.resolve_hostname
searchguard.ssl.transport.enabled_protocols
searchguard.ssl.transport.enabled_ciphers
This is what we have for ROR.
readonlyrest:
enable: true
ssl:
keystore_file: "keystore.jks"
keystore_pass: readonlyrest
key_pass: readonlyrest
Based on the code in BasicSettings class, I am going to guess, this is what it will need to look like.
readonlyrest:
ssl:
enable: true
keystore_file: "keystore.jks"
keystore_pass: readonlyrest
key_pass: readonlyrest
ssl_internode:
enable: true
keystore_file: "keystore.jks"
keystore_pass: readonlyrest
keystore_alias: mycertalias
key_pass: readonlyrest
allowed_protocols: ["TLSv1.2"]
Does this look right? Also, what about host name verification and resolve hostname?
Thanks!
Yeah looks ok. The Trust store can be managed via JDK I believe. We don’t have specific options.
We added the “verification” key to our SSL options, it’s “true” by default for internode, and “false” by default for the HTTP interface.
verification: true
Hi,
I deployed readonlyrest version 1.17.0 on an elasticsearch 6.6.1 cluster. I managed easly to enable SSL on the HTTP protocol but I’m facing issues for enabling it on the transport protocol.
I tried to add the following config :
ssl:
enable: true
keystore_file: "readonlyrest.jks"
keystore_pass: "XXXXXXi"
key_pass: "XXXXXXX"
allowed_protocols: ["TLSv1.2"]
ssl_inteirnode:
enable: true
keystore_file: "readonlyrest.jks"
keystore_pass: "XXXXXXX"
key_pass: "XXXXXXXX"
allowed_protocols: ["TLSv1.2"]
But it seems that SSL is still not enabled on transport protocol.
After checking the source code, I also tried to add the following line in the elasticsearch.yml config file.
transport.type: "ror_ssl_internode"
And now I have the following java exception :
[2019-03-05T17:12:57,943][ERROR][o.e.b.Bootstrap ] [inf-c-esc-001] Exception
java.lang.IllegalStateException: Unsupported transport.type [ror_ssl_internode]
at org.elasticsearch.common.network.NetworkModule.getTransportSupplier(NetworkModule.java:216) ~[elasticsearch-6.6.1.jar:6.6.1]
at org.elasticsearch.node.Node.<init>(Node.java:500) ~[elasticsearch-6.6.1.jar:6.6.1]
at org.elasticsearch.node.Node.<init>(Node.java:265) ~[elasticsearch-6.6.1.jar:6.6.1]
at org.elasticsearch.bootstrap.Bootstrap$5.<init>(Bootstrap.java:212) ~[elasticsearch-6.6.1.jar:6.6.1]
at org.elasticsearch.bootstrap.Bootstrap.setup(Bootstrap.java:212) ~[elasticsearch-6.6.1.jar:6.6.1]
at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:333) [elasticsearch-6.6.1.jar:6.6.1]
at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:159) [elasticsearch-6.6.1.jar:6.6.1]
at org.elasticsearch.bootstrap.Elasticsearch.execute(Elasticsearch.java:150) [elasticsearch-6.6.1.jar:6.6.1]
at org.elasticsearch.cli.EnvironmentAwareCommand.execute(EnvironmentAwareCommand.java:86) [elasticsearch-6.6.1.jar:6.6.1]
at org.elasticsearch.cli.Command.mainWithoutErrorHandling(Command.java:124) [elasticsearch-cli-6.6.1.jar:6.6.1]
at org.elasticsearch.cli.Command.main(Command.java:90) [elasticsearch-cli-6.6.1.jar:6.6.1]
at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:116) [elasticsearch-6.6.1.jar:6.6.1]
at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:93) [elasticsearch-6.6.1.jar:6.6.1]
[2019-03-05T17:12:57,951][WARN ][o.e.b.ElasticsearchUncaughtExceptionHandler] [inf-c-esc-001] uncaught exception in thread [main]
org.elasticsearch.bootstrap.StartupException: java.lang.IllegalStateException: Unsupported transport.type [ror_ssl_internode]
at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:163) ~[elasticsearch-6.6.1.jar:6.6.1]
at org.elasticsearch.bootstrap.Elasticsearch.execute(Elasticsearch.java:150) ~[elasticsearch-6.6.1.jar:6.6.1]
at org.elasticsearch.cli.EnvironmentAwareCommand.execute(EnvironmentAwareCommand.java:86) ~[elasticsearch-6.6.1.jar:6.6.1]
at org.elasticsearch.cli.Command.mainWithoutErrorHandling(Command.java:124) ~[elasticsearch-cli-6.6.1.jar:6.6.1]
at org.elasticsearch.cli.Command.main(Command.java:90) ~[elasticsearch-cli-6.6.1.jar:6.6.1]
at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:116) ~[elasticsearch-6.6.1.jar:6.6.1]
at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:93) ~[elasticsearch-6.6.1.jar:6.6.1]
Caused by: java.lang.IllegalStateException: Unsupported transport.type [ror_ssl_internode]
at org.elasticsearch.common.network.NetworkModule.getTransportSupplier(NetworkModule.java:216) ~[elasticsearch-6.6.1.jar:6.6.1]
at org.elasticsearch.node.Node.<init>(Node.java:500) ~[elasticsearch-6.6.1.jar:6.6.1]
at org.elasticsearch.node.Node.<init>(Node.java:265) ~[elasticsearch-6.6.1.jar:6.6.1]
at org.elasticsearch.bootstrap.Bootstrap$5.<init>(Bootstrap.java:212) ~[elasticsearch-6.6.1.jar:6.6.1]
at org.elasticsearch.bootstrap.Bootstrap.setup(Bootstrap.java:212) ~[elasticsearch-6.6.1.jar:6.6.1]
at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:333) ~[elasticsearch-6.6.1.jar:6.6.1]
at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:159) ~[elasticsearch-6.6.1.jar:6.6.1]
... 6 more
Any help ?
Thank you.
this is a spelling error