Prototyping…
Looks a bit off visually, but this is what you guys meant, right?
1 Like
No. I was thinking something like this. You can have a ROR logo, clicking on which you will get a dropdown/menu and then you show the logged in user details. Later on if you want to expand this to add other options like create role, add ACL etc, you can expand on this, as this option gives that flexibility. You could as well have a proper “Logout” option as the last item on the menu/dropdown.
2 Likes
Ohh amazing, yes the way you showed is much better.
!Yes - this looks excellent!
1 Like
This looks great! I am assuming “Logged in as” is the username. Is that correct?
Also, for free version, I am assuming that tenancy section will be hidden.
1 Like
Yes “logged in as” is the label for username, is it unclear? Suggestions?
Yes the idea is that when no tenancies are available (due to configuration or non-enterprise edition) the button disappears.
"Another thing I was thinking is that the “Go to settings” button will replace the sidebar button, and will disappear automatically if you are not admin or unrestricted.
This will remove the user from the burden to add
kibana_hide_apps: ["readonlyrest_kbn"]
to the ACL all over the place for non admin users.
This is good idea. But how will this work in the context of Kibana spaces, as all apps can be enabled or disabled via spaces configuration, also given that ROR does not currently support.applying security for spaces.
@askids it won’t appear in he list of features when configuring a space. It will just be a button to configure ROR that you will see in your new ROR panel, whenever you have privileges.
Do you see any limitation in this?
As long as ROR does not appear as an app that can selected from Kibana spaces, I think that we should be fine, going with this approach.
Also, I am assuming that at individual ROR setting page level also, you will some sort of check to cross verify that its an actual admin who is logged in. If somebody just has that direct link, we should still prevent non-admin users from accessing that page.
Also, do you plan to provide separate links to Audit Dashboards or discover audit logs? In that case, it may be worthwhile to simply put it as a “Settings” list item instead of a button. That will allow you to keep expanding that list with other features in future and still keep a consistent experience. Only logout can continue to be a button.
I am side tracking a bit. For audit logs, you should also look at publishing some standard visualization and dashboards as part of the Kibana Plugin that users could use out of the box with the plugin. To support that you will also need to probably automate creation of index pattern as part of the initial plugin load process. If you want community contribution for visualizations/dashboard, please do some further brainstorming on how to support it properly (since visualization will depend on the index name pattern and the index name used, may vary from one client to another, you will need to figure out contribution guidelines). In most cases, it may look like a simple export of their existing visualization. But it wont be that simple due to possibility of varying index name across deployments. So will need to figure that out.
@askids yes! Thanks for this precious feedback!
To summarise:
1.Non-admin (kibana_access: ro/rw/ro_strict) users won’t see the “got to settings” button in the new panel
2. spaces settings won’t list ROR as an app anymore
3. No more need to write hide_kibana_apps: [“readonlyrest_kbn”] for non-admins
4 if a non-admin tries to navigate to ror settings page, they will be bounced to Kibana main page
The page dedicated to audit log is today incorporated with the security settings (yaml editor page). So it is available only to administrative users.
In the next version, we’ll explore the expansion of that go to settings button into a group of links to aspects of ROR, including settings and the audit page and future features, great point!
@askids I’m not sure if you noticed it, but as of today there’s already a “one-button” add index pattern + dashboard that builds on top of readonlyrest audit logs. Give it a try and please consider making it better and sharing it back 
But as you suggest, I will create a dedicated forum topic.
Hi @sscarduzio,
We’ve recently updated to 1.19.5 and think we are seeing a bit of an issue, specifically with regard to #1 above re. non-admin users.
The problem is that (per documentation point below) for our admin users, we don’t explicitly set admin level, rather we remove the rule. It looks like the new updates are not recognising these types as admin, and are therefore blocking access to ROR settings.
Hope that make sense - let me know what you think.
Regards,
Adrian
From the docs :
NB: The “admin” access level does not mean the user will be allowed to access all indices/actions. It’s just like “rw” with settings changes privileges. If you want really unrestricted access for your Kibana user, just remove the kibana_access rule entirely.
Can you try with kibana_access: "unrestricted"?
it doesn’t seem to recognise that option:
Error: Failed to save the security settings: “Cannot reload new settings: Errors:\nUnknown kibana access ‘unrestricted’”
I see a few commits around this - is that setting available in 1.19.5?
@aidofitz yes it’s included but a bug prevents you from using it. I’m preparing a hotfix. What ES version do you have?
we’re planning to move to 7.7 along with moving to latest ROR version, thanks. Not crazy urgent for us, we’ve only got this issue in a test cluster for now!
thanks, we’ll test that if we get a chance, but we might just wait for 1.20 to be GA!
Just to clarify, will the fix be to that we’ll need to use “kibana_access: unrestricted”, and/or does it fix that an absent kibana_access is picked up as an admin status ?
1 Like
The fix is that kibana_access: unrestricted is passing settings validation and will show the settings button.