“And search-guard cannot run by it self , why not put search-guard-2 and search-gruad-ssl togther ?”
Valid question! Indeed, Search Guard 1 combined both the SSL/TLS layer and auth/auth in one plugin. We decided to split this in two plugins because for a number of users out there, running the SSL plugin only is actually sufficient. With SSL/TLS, you can ensure that:
- Your data cannot be sniffed (encryption)
- Your data cannot be tampered with (signing)
- Only authenticated clients can connect (client auth)
Many companies already have a PKI infrastructure in place, and do not need full fledged auth/auth. For them it is sufficient to ensure that only verified clients can connect to their cluster. For that, you only need the SSL plugin. So, you can say that this was upon user request.
TLS on the REST layer is indeed optional, while it is mandatory on the transport layer. Without TLS on the transport layer, authentication and authorization does not make much sense from a security point of view.
We do get a lot of questions about this, and we will extend the docs and also write some blog post about the whys, to make this more clear. We also understood that setting up both plugins can be quite cumbersome. We will improve the setup of the plugins in near future, and already provide a pre-configured bundle for a quick start:
Am Donnerstag, 30. Juni 2016 18:57:45 UTC+2 schrieb Jay Miao:
I find “HTTP SSL is optional” on the README file of search guard 2.
But when I read the search-guard-docs it seems SSL certification is a must from the start to the end.
I deploy my elasticsearch in a safe inner-network, so I guess I just need a Http-base Auth not generating root certification, node certification … put them to the right place one by one… err…
So I doubt HTTP SSL is a compulsory.
And search-guard cannot run by it self , why not put search-guard-2 and search-gruad-ssl togther ?