Dashboard user and dashboard crator user

Hi all.

I'm playing with the x-pack features, and, once I have some data on a few indices, I want to achieve the following:
I would like to have an user that is able to create dashborads, so it is granted explore, visualization and dashboards from just its indices. Then, I would like to have another user that can just see the dashboards.

So far, I've created two spaces that shows just 'show' relevant kibana tabs.
I have created a pair of roles that have just read access to those Indices, and that grant read to the 'shown' kibana tabs denying access to the 'hidden' tabs
I have created the two users, and have assigned each one its space.

I'm facing two early issues:
First and foremost, Kibana complains It needs an index pattern to retrieve data, which is logic, so ... how can I provide those users their pattern?
The management tab is shown, although its areas are secured... is this tab really needed? can't it be hidden?

Thank you very much in advance.
Best regards.

Hi @alexolivan,

For your first problem, it makes sense to create this index pattern as a super user in the space once. Then the users will be able to work with it.

Hiding the management app completely is currently not possible, there is an open issue for this in the Github repository if you want to follow along: https://github.com/elastic/kibana/issues/35040

Thank you very much for your help!

So I need to temporary activate the Manage Index Patterns UI option, switch to those spaces while as elastic user, generate the index pattern, and then disable the UI again... isn'it?

I'm just learning how these Kibana + xpack combo is intended to be used... and now I doubt whether two spaces fit on this scenario:
If I have two spaces, one per user, seeking 'don't see what cant touch' UI policy, then all the work creating visualizations and dashboards of one user would be, therefore, missing on the other user's space ... isn't it?
...if so it is, then in order to share dashboards/visualizations, i guess they must share a same space/UI, and let restrictions set at user-role level to control access to what they actually see... or can they share dashboards/visualizations from different spaces?



I think I got it now ... It was unclear to me the UI behaviour/impact upon role-based space restrictions, because of the UI control at space itself: Now I see that denying access at role-level, UI features are hidden.
So, here, I conclude that same-space is the way to go.
Space UI restrictions state what AT THE MOST a user would see there, letting role-based space restrictions to further cut-down the UI.

I think you got it right, you can do both - lock down the whole space or just for some users. If you want to have users to have both private and shared visualizations and dashboards, you could also create a third space both have access to in addition to the user-private spaces. This way everyone can develop their stuff in private and then copy over the saved object into the shared space (you can do that in the saved object management) when they want to make it accessible by everyone.

However that’s not the right approach for all cases, I’ve seen a lot of users just prefixing the names of their visualizations with their username to have a differentiation without having to resort to spaces and copying saved objects around.

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.