‘searchguard.enabled’ is not a valid configuration key for SG2. It was in SG1, but has been removed.
Running SG without TLS on transport level is not possible at the moment since parts of our security infrastructure rely on node verification via TLS. Theoretically, we could make that configurable, but that would open a plethora of attack scenarios and security holes. We know that it is possible to switch TLS off in other ES security products, but we made a deliberate decision to not allow that in SG.
We can, of course, reconsider this decision, but we’d like to know how it would make zero-downtime deployments possible. Let’s say you have installed SG without TLS via a rolling restart. In order to turn TLS on, you would still need to take every node down, one by one, enable TLS and restart the node. During this process, you will still end up with a split cluster, where TLS enabled nodes are not able to talk to TLS enabled nodes. So, can you shed some light on the rollout scenario you have in mind?
On Wednesday, 9 November 2016 10:30:25 UTC+2, firstname.lastname@example.org wrote:
Same question. Using version 2.4.1.
Is it possible to have the plugin installed but ssl turned off? (this is a very important issue for transitioning a cluster to SG-SSL without downtime)
On Friday, April 8, 2016 at 10:21:36 PM UTC+3, in...@search-guard.com wrote:
which SG and elasticsearch version?
Am Mittwoch, 6. April 2016 20:52:33 UTC+2 schrieb m...@rrd.com:
I don’t understand why I am experiencing this error when Elasticsearch attempts to start, when I have already specified ‘searchguard.enabled: false’ in elasticsearch.yml ::
Exception in thread “main” ElasticsearchException[searchguard.ssl.transport.keystore_filepath must be set if transport ssl is reqested.]
If it is not enabled, why am I experiencing this error regarding the keystore?
Is there any documentation for configuring this setting, and any steps to take before that?