I think there’s a confusion here between the REST/HTTP layer and the transport layer. When talking about “nodes joining a cluster”, you have to look at the transport layer, not the REST layer.
In short, shasm is correct here. On the transport layer, mutual authentication is mandatory and it cannot be switched off.
In a typical client/server scenario (which means “webserver”), only the TLS certificate of the server is validated by the client (which means “browser”). By default, the client does not need to identify itself to the server. TLS is not limited to this, and we support client authentication on the REST layer as well. This can be enabled, be optional, or switched off.
On the transport layer, mutual authentication is mandatory and it cannot be switched off. If a node talks to another node:
The first node sends its certificate along with the request (from its keystore)
The second node receives the certificate and validates it (against its truststore)
The second node sends an answer and also sends its certificate (from its keystore)
The first node receives the answer and the certificate, and validates the certificate (against its truststore)
So by default, no unauthenticated node can join the cluster. For additional security, you can also use
See also your other post on this: https://groups.google.com/forum/#!topic/search-guard/surZWa04Cc0
Am Donnerstag, 15. Dezember 2016 19:54:57 UTC+1 schrieb Lin Dwell:
Since in a SSL Session handshake , only server is authenticated by default. In Search gurad, how can we enforce the mutual authentication so that the client node is also authenticated . I understand that an es node can act as both client and node, but this may not seem sufficient to prevent an unapproved node from joining the cluster because unapproved node will act as a client until the point it doesnt receive requests from other nodes. Please correct my understanding if i am wrong.
Will this setting help ?
Is the setting supported for Search Guard 2.4.1