RoR active, still able to changed fields in indexes?

1

I have installed the RoR plugin on ES, version in use is 1.16.8 for ES 5.4.2. This is configured according to Make Kibana read only for domain other than localhost - #4 by sscarduzio, see the GitHub resource.

I basically have a read-only account, and an admin account for Kibana. This works as expected. With the read-only account, I can not save changes to dashboard or visualizations for example.

What I found out today though, is that I can go to: Management > Index paterns, select an index, and change a field. I do get a login prompt, but I can cancel this. Make changes to an index field attribute, click the ‘Update Field’ button and the change is indeed accepted.

Is this a bug in the RoR plugin, or in my configuration?

2

Hello @anon539667!
Is it so that if you refresh the page the change has actually taken effect?
Are you able to see the log line corresponding to the request associated to the change?

3

Yes, confirmed on your first question. When I reload the page, the change has taken effect.

As for your second question, I’ll see if I can check my log right now to see if I can catch those lines. Will post them here asap.

1 Like
4

As soon as I click on the Field edit button, I can see the following in my log:

[2017-08-02T17:40:26,442][INFO ][o.e.p.r.a.ACL ] FORBIDDEN by default req={ ID:1701760699-56097877#2317433, TYP:ClusterStateRequest, USR:[no basic auth header], BRS:false, ACT:cluster:monitor/state, OA:127.0.0.1, IDX:, MET:GET, PTH:/_cluster/settings?include_defaults=true&filter_path=**.script.engine.*.inline, CNT:<OMITTED, LENGTH=0>, HDR:Connection,Content-Length,Host, HIS:[::KIBANA-SRV::->[auth_key_sha256->false]], [::RW DEVELOPER::->[auth_key_sha256->false]], [::RO DEVELOPER::->[auth_key_sha256->false]] }

This is also when I get an authentication popup. I can cancel this login, and then edit the field and update it. There are no further entries in the log after that.

5

That log line testifies the presence of a long standing bug in Kibana such that unauthenticated requests are sent to Elasticsearch.

However, this is unrelated to the bug at hand. We’re looking for an ALLOWED request (as the change is allegedly happening in the index).

Consider also that the plain “ro” access does let something through intentionally.

See the difference between ro and ro_strict here:
https://readonlyrest.com/documentation/#Rules--Elasticsearch_level

PS: Full disclosure, I just documented it.
PPS: Relevant code on what’s allowed in ro mode:
https://github.com/sscarduzio/elasticsearch-readonlyrest-plugin/blob/master/core/src/main/java/org/elasticsearch/plugin/readonlyrest/acl/blocks/rules/impl/KibanaAccessSyncRule.java#L127

6

So can I fix this by setting the read-only ‘user’ from ‘ro’ to ‘ro-strict’ in my RoR config?

7

Try that, yes. ro_strict with underscore.

8

That fixed it! Thanks so much for the quick support :slight_smile:

1 Like
9

No problem, glad it works :slight_smile:

1 Like