Limited access user : role 'kibana_user' can still manage spaces

Hi all, and thx a lot for those wonderful ELK tools.

I'm trying to configure a limited-access user, able to only create visualizations for a given space, limited to a specific index, with ELK 7.6.0. User shall not be able to change data itself nor Kibana config, just use it to produce visualization, dashboards and discover data.

index : 'lolo'

space 'lolo' : 
     show only discover, visualize, dashboard features

role 'lolo_role' :
    index privileges :
        index : 'lolo' => read, view_index_metadata
        index: '.kibana*' => read, view_index_metadata
    space privileges :
         space 'lolo': 'all' to discover,visualize,dashboard, none otherwise

user 'Laurent' : 
       Roles : 'lolo_role', 'kibana_user'

Problem :
This user has still access to the 'Management/Kibana/Spaces' menu and is free to do whatever he wants there (create/delete spaces), while I was expecting this menu to be disabled or hidden in such case.

Same config but when removing the 'kibana_user' from user roles, works fine for discover, except that I get 2 error messages when consulting data :

  -> `Unable to update UI setting : Request failed with status code: 403`
  -> `Error fetching fields for index pattern lolo :  Forbidden'`

but it can still show index contents however.

Is there anything I misunderstand, some additional access rights I shall assign to the .kibana indices for my role ?

Moreover, 'kibana_user' is marked has being deprecated in documentation :
Using 'kibana_admin' leads to same effect, which then make me think that there might be a 'read-only' user and/or 'use -but-don't-admin' user missing in kibana documentation ?



When you assign a user multiple roles, the user receives a union of the roles’ privileges. Therefore, assigning the kibana_user role in addition to a custom role that grants Kibana privileges is ineffective because kibana_user has access to all the features in all spaces.


thanks for your answer,
I understand that from several roles, the union will be applied. Since 'kibana_user' gives 'admin' rights on Kibana app, spaces will be configurable by this user.

So the problem here is what role / rights shall I assign to the user so that it can use Kibana features discover/visualize/dashboard, only over a set of given spaces (and associated index patterns), without giving the right to administrate Kibana app, nor interfer on spaces/indices he shall not have access to.

I tried to set-up privileges as tights as I could as described in my initial message, as far as I understood security features in Kibana, but could not manage to get such a result.

From this example, if I remove the 'kibana_user' role, GUI seems to be as expected, but then when using it some error pops-up ("Error fetching fields for index pattern xxx : Forbidden"), even if the user roles give access to related user index and .kibana* indices.

In short, is there a role giving full access to discover/visualize/dashboard apps without giving admin rights on 'Kibana app'?

Thx again for your help!

by the way, the link you gave in previous answer seems to be outdated, get page with text "Moved Permanently. Redirecting to /fr/opt/node_apps/new404.html]("

In short, is there a role giving full access to discover/visualize/dashboard apps without giving admin rights on 'Kibana app'?

Nothing built-in, but it’s easy to create a custom role to do so.



I could investigate more deeply, I think my problem is actually very similar (if not the same) to Kibana "error fetching fields" forbidden

So I have a user whose role gives 'read' and 'view_index_metadata' access to a given index, and working in a space (and index-pattern) dedicated to this index.

Important point : all of those (user, index, space, index-pattern, role) are created through REST API.

Problem: when user logs-in after creation of its account and related space and index etc, he gets following error from Kibana GUI:

Error fetching fields for index pattern xxx : Forbidden

BUT once another user with 'kibana_admin' or similar rights access the same space, the problem then is solved for my user.
Following the issue I've pointed out, the problem seems to be recurrent every 24h.

The offered solution in this issue is just to give 'kibana_user' role to my user, which is not acceptable solution because then he has admin access to Kibana (and so can just destroy all spaces he shall not have access to...).

Giving 'all' access to .kibana* indices does not fix the problem.

I suspect some recurrent processing in Kibana requiring 'kibana admin' role.

Acceptable solution would be if such 'refresh' operation could be invoked through REST API, like a 'GET' operation that would indirectly perform the refresh. I could then plan it to be run every few hours from my application (using 'elastic' user credentials), but could not find any so far.

Hope this is now more clear ...


@Larry_Gregory can you please help when u get some time here?


Hi @laurentml, and welcome to the discussion boards!

I'm sorry for the frustrations you're having so far. I haven't been able to pinpoint this just yet, but it looks like you're seeing a similar manifestation of

You're absolutely right the the kibana_user/kibana_admin roles grant full access to spaces management. This is something we want to improve - please feel free to vote on so we can try to prioritize this appropriately.

We deprecated kibana_user in favor of the kibana_admin role. The reason for this change is outlined in

As Kibana has evolved, the kibana_user and kibana_dashboard_only_user role names are becoming rather confusing.
These roles are no longer the absolute minimum privileges that a user needs to access Kibana, and kibana_user is more-so the "Kibana superuser" and kibana_dashboard_only_user is a "All of Kibana read-only user". I'm less concerned with kibana_dashboard_only_user because "Feature Controls" should be making this functionality redundant; but kibana_user is my primary concern.
Since renaming this role automatically isn't feasible, the current plan is to create a kibana_admin role; and to deprecate the existing kibana_user and kibana_dashboard_only_user roles for the 7.x lifecycle. We'll need to determine the best way to denote that this role is deprecated, and warn the user that it will be removed in 8.0. Ideally, the 8.0 upgrade assistant will be able to handle the switch for us as long as the user is using the native realm. This will give the users adequate time to transition to the new role.

This rename has no bearing on your current problem though.

I'm nearing the end of my day, but I'll try to spend some time this week tracking this down further.

Thanks a lot for your fast answer,

Nice to see that problem is somehow on track (i've up-voted).

Looking forward hearing from it, but no life-or-death hurry for me, my app will start 'beta-testing' this summer, so we can live with it for few months I guess.


1 Like

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