How to block nodes status/cluster health information from readonly users

[Kaushik Dutta]

Hello, 

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.

Respectfully,

Kaushik Dutta

[SG]

Do NOT grant the following permissions for them:

cluster:monitor/nodes/info
cluster:monitor/health

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!!
(https://groups.google.com/forum/#!topic/search-guard/opmLtekzLeg)

> --
> 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.

[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 :/

[SG]

As we said: Search Guard 1 is no longer supported. The answer that was given works with Search Guard 2. Issue #24 is also fixed for SG2.
There was no hint in the first mail so i assumed its about SG 2.

Sorry if you feel disappointed about 1.x discontinuation, therefore we offer now paid services which guarantees that that will not happen again
and focus on the needs of enterprises. See https://floragunn.com/searchguard/searchguard-license-support/

BTW: 1.x is not vanished, its here https://github.com/floragunncom/search-guard-attic

> To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/295cdbab-96cf-4066-901d-cb425ab7f77e%40googlegroups.com.

[Jochen Kressin]

Hi,

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:

https://groups.google.com/forum/#!topic/search-guard/_rfXnjijE3M

Thanks,

--

Jochen Kressin

CTO

floragunn UG (haftungsbeschränkt)

Tempelhofer Ufer 16

10963 Berlin