The documentation around this setting is in my view a bit ambiguous, particularly with regard to the RO and RW settings. For these in particular, the text currently “some write requests can go through”, “some more actions will be allowed” is a little unclear. Does it mean that the only access granted to user by these setting is that described at the end of those sentences - i.e. “UI state in discover can be saved and short urls can be created” & “Kibana dashboards and settings can be modified” - or is it some accessing, including but not limited to these items?
I want to give users access such they can created Saved Searches, and it’s not clear from the docs what the minimum level required for that is. I guess RW, and obviously I can do some experiments to find out, but wanted to highlight that I think the documentation could be improved here!
A further clarification - I’m wondering if there is an access level which will give access to create Save Searches, Dashboards etc. but without potentially allowing users a way to change kibana settings and (inadvertently or otherwise!) damage the system in some way!
Our intent with kibana_access: <ro_strict|ro|rw> is to prevent accidental or intentional changes to the cluster configuration and to any data index.
What is a data index? Any other index other than the ones under the scope of kibana (i.e. .kibana*, .reporting*, etc).
ROR settings and cluster management are currently enabled to kibana_access: admin, but not the direct writing/updating/deletion of documents of any data index
Instead, we restrict kibana_access: rw to simple CRUD permissions to kibana objects (visualizations, index patterns, dashboards, etc).
The kibana_access: ro users cannot make any changes to the kibana objects. The “edit”, “new”, “delete” buttons are removed from their UI.
You can instead use kibana_access: ro_strict if you want users to leave zero traces on Kibana at the cost of some features not working, like the button for creating short links (which needs to save a record in Kibana in order to work).
As far I can tell, I think for your use case “rw” is the right one.
