Upgraded from 5.4.0 to 5.6.0 Now wont start

Sure!

name=readonlyrest
version=1.16.10
description=Safely expose Elasticsearch REST API
classname=org.elasticsearch.plugin.readonlyrest.es.ReadonlyRestPlugin
java.version=1.8
elasticsearch.version=5.6.0

ES 2.x compatibility

site=false
jvm=true
isolated=false

Oh I see what’s wrong. The new experimental code to read the settings from readonlyrest.yml ended up in the 5.5.3 and 5.5.0 because Elastic has released those new version right after ROR 1.16.10 was released.

A fix is coming, hold on @cronin.

Can you please try again with this build?

https://readonlyrest-data.s3-eu-west-1.amazonaws.com/tmp/readonlyrest-1.16.11-pre4_es5.6.0.zip?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAJEKIPNTOTIVGQ4EQ/20170913/eu-west-1/s3/aws4_request&X-Amz-Date=20170913T161938Z&X-Amz-Expires=604800&X-Amz-SignedHeaders=host&X-Amz-Signature=52d1861bf74bb869be4f0f0cfe44dda502fba81dd7b43482b9e460a2a5887d51

YES! Worked perfect!!!

Now upgrading Kibana and installing ROR Enterprise. Very exciting.

1 Like

Awesome! If you have any questions or issues, just tell me. Enjoy!

Follow up question in ROR Enterprise how do I enable the “Group/Tenancy selector” in Kibana?

Hi @cronin, see the video and attached configuration example here:

Thanks for this I’m noticing some odd:
When I make changes to ROR settings in my .yml file they don’t take hold when I look back in Kibana I still see my old settings. is this intential? Should I make all chnages moving forward in Kibana?

Yes the Settings UI saves the configuration on an index, and the index settings have priority at node start up.

The lifecycle of the settings is intended like this

  1. Set up the basic failsafe credentials and ACL in the ES node’s YAML file (i.e. credentials for kibana server, logstash, and ROR admin).
  2. Get the Kibana plugin up and running and log in as administrator
  3. Open the Settings UI from Kibana. If this is the first time, it will inherit whatever settings it reads from the YAML file (to give you a starting point)
  4. Tweak the settings, hit the commit button and they are saved in the .readonlyrest index (ES settings automatically picks up the changes)
  5. From now on, even if you restart the ES node, the settings are going to be loaded exclusively from the .readonlyrest index and can be edited from Kibana only.

If you want to revert to file-based settings

  1. back up the YAML you see in the Settings UI
  2. write those settings to the node’s YAML file
  3. delete the readonlyrest index from ES
  4. restart the node

Okay @sscarduzio last few question I swear…
Currently when applying kibana rw rules Im applying them at the group level like so:
name: "::XXX::"
groups: [“XXX”]
kibana_index: ".kibana_xxx"
kibana_access: rw

But can I apply them at the user level instead like this:
users:

  • username: greg
    auth_key_sha256: "ABC"
    kibana_access: rw
    groups: [“XXX”]

#groups Below
name: "::XXX::"
groups: [“XXX”]
kibana_index: “.kibana_xxx”

Also same question for kibana_hide_apps.

Hi @cronin, in the blocks under under the “users” section you should only have the “group” rule to define what groups are associated to this user, and some authentication related rule (e.g. auth_key, auth_key_sha256, etc).
Although some more advanced things are possible like LDAP + local groups. But that’s another story.

Does this answer your question?

Not exactly. Let me rephrase a bit here is an example of my new user settings:
-
name: "::XXX::"
groups: [“XXX”]
kibana_index: “.kibana_XXX”
-
name: "::XXX_RO::"
groups: [“XXX RO”]
kibana_index: ".kibana_XXX"
kibana_access: ro
kibana_hide_apps: [“readonlyrest_kbn”, “timelion”, “kibana:management”, “kibana:discover”, “kibana:visualize”, “kibana:dev_tools”]
users:

  • username: greg
    auth_key_sha256: "XYZ"
    groups: [“XXX”, “XXX RO”]

Now this works as expeted however the readonly group “XXX RO” can still edit and crate items in dashbaords. My understanding is that the “RO” flag would prevent that from happening.

I’m testing this with the example settings you provided. One thing I didn’t mention is that all indices need to be lowercase, the example should have kibana_index: ".kibana_xxx"

Beside that, to your point. I actually reproduced the issue in the sense that I could get a green confirmation message when I add a viusalization to the dashboard, but when I refresh my dashboard doesn’t have the visualization added.
Can you confirm you see the same?

Yes, that’s exactly what I’m saying. Also if you edit a dashboard edit an element and save you get a 400 error and then logged out.

Also to your point all my indexes are lowercase I just removed client names and replaced with XXX.

So basically the expected behaviour would be to get the 400 without the logout, I guess?

I mean to be honest the ideal scenario would be if you have RO access you shouldn’t even see the Edit buttons in the UI I mean what’s the point if you can only read?

But yes if that’s not possible there should be no logout just a 400 that it couldn’t save.

1 Like

Hi Simone

I have the same problem starting elasticsearch 5.6.

Error injecting constructor, java.security.AccessControlException: access denied (“java.io.FilePermission” “config/readonlyrest.yml” "$
at org.elasticsearch.plugin.readonlyrest.es.ReloadableSettingsImpl.(Unknown Source)
while locating org.elasticsearch.plugin.readonlyrest.es.ReloadableSettingsImpl
for parameter 5 at org.elasticsearch.plugin.readonlyrest.es.IndexLevelActionFilter.(Unknown Source)
while locating org.elasticsearch.plugin.readonlyrest.es.IndexLevelActionFilter
while locating org.elasticsearch.action.support.ActionFilter annotated with @org.elasticsearch.common.inject.multibindings.Element(setNam$
at unknown
while locating java.util.Set<org.elasticsearch.action.support.ActionFilter>
for parameter 0 at org.elasticsearch.action.support.ActionFilters.(Unknown Source)
while locating org.elasticsearch.action.support.ActionFilters
for parameter 2 at org.elasticsearch.index.reindex.TransportDeleteByQueryAction.(Unknown Source)
while locating org.elasticsearch.index.reindex.TransportDeleteByQueryAction
Caused by: java.security.AccessControlException: access denied (“java.io.FilePermission” “config/readonlyrest.yml” “read”)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)

This is my plugin version

name=readonlyrest
version=1.16.10
description=Safely expose Elasticsearch REST API
classname=org.elasticsearch.plugin.readonlyrest.es.ReadonlyRestPlugin
java.version=1.8
elasticsearch.version=5.6.0

Could you help me please

regards

Hi @cronin!
You can already download from the website the 1.16.11-pre5 which has a fix for that.

Hi @sscarduzio, it worked, thanks for your help

1 Like