I’m sorry to read that your experience was not cool. Let me jump in here and take the chance to explain. First, there seems to be some confusion about the SG version in use.
The way that configuration settings (including usernames and passwords) are stored changed completely from SG1 to SG2. All SG settings are now stored in an secured index, making it possible to hot reload the configuration, and making sure that these sensitive informations do no leak. We surely understood your problem, but it applies to SG1 and not SG2. SG2 does not have this issue any more. That’s why we wrote “there should not be any password there”, referring to SG2. Sorry if this was not clear from our answer.
Regarding the discontinuation of SG1: We did announce that on a public post on Google Groups on 25th of February:
“We decided to take the project to the next level with the release of SG2 while at the same time slowly fading out the development for SG1. We will dedicate substantially more time and resources for SG2 in 2016, and provide new releases and support on a regular basis.”
Agreed, we could have made this decision a little bit more prominent, and I take the blame for that.
I understand that the discontinuation might create some trouble for users who are not able to upgrade. But also understand that we neither have the financial power nor the development powers to maintain SG1/ES1, SG2/ES2 and (soon) SG5/SG5 at the same time.
SG1 is completely free (as in free beer), including the now dual licensed features like LDAP, Kerberos, DLS/FLS etc. The complete code has been contributed to the community, and we would be more than happy if the community would fork the repository and continued to provide patches and bug fixes for SG1. But since we do not get much requests for SG1 anymore, there are no sources of revenue from SG1, and we need to pay our developers, it was mandatory for us make this cut. Otherwise we would have not been able to continue with Search Guard
Please also read my post from 25th of February, explaining our decision a little bit more:
floragunn UG (haftungsbeschränkt)
Tempelhofer Ufer 16
Am Mittwoch, 15. Juni 2016 21:46:32 UTC+2 schrieb Arghanil Mukhopadhyay:
That doesn’t work at all.
As search guard has written down the limitations, https://github.com/floragunncom/search-guard/tree/8040165fd0e294876ba8314dc6709156d50679f3#limitations
- Currently monitoring of the cluster needs no authentication and is allowed always (this may change in the future)
That displays all the roles, filters, userid, password to all authenticated user. So NOT sure why you didn’t understand the question.
What do you mean by “there should not be any password there”? The elasticsearch.yml file has the search guard configuration, which ends up getting displayed in the cluster APIs.
Also there is a bug https://github.com/floragunncom/search-guard/issues/24 for which even the digest method doesn’t work. The fix never ended up in any of your release release (not RC or just snapshot)
Also it was a surprise to see versions like 1.7.3 discontinued (actually vanished) within last 2-3 months when there is not even a GA release!
It’s not that easy for any enterprise to change the production environment overnight to match up to that.
Sadly the experience has not been cool
On Tuesday, June 14, 2016 at 2:16:41 PM UTC-6, SG wrote:
Do NOT grant the following permissions for them:
What do you mean with that ‘http://localhost:9200/_nodes/?pretty’ lists down all information including all user-id & password combinations for Elasticsearch?
There should not be any password in there. Pls. make sure do you use Search Guard 2 for Elasticsearch 2. Search Guard for Elasticsearch 1.x is no longer maintained!!
Am 14.06.2016 um 22:02 schrieb Kaushik Dutta kaud...@gmail.com:
Basic authentication & authorization is working for us using Search Guard; however any authenticated user (including read-only users) can run the following to queries:
curl -u readOnlyUser -XGET ‘http://localhost:9200/_nodes/?pretty’
curl -u readOnlyUser -XGET ‘http://localhost:9200/_cluster/health?pretty’
We need to block the first query at least, as it lists down all information including all user-id & password combinations for Elasticsearch.
Any help in this regard is highly appreciated.
You received this message because you are subscribed to the Google Groups “Search Guard” group.
To unsubscribe from this group and stop receiving emails from it, send an email to search-guard...@googlegroups.com.
To post to this group, send email to search...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/22303db2-0f54-4232-9d85-f6e2e9db2828%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.