Kibana 5.2 ignores document level security on .kibana

Elastic Stack Kibana
1

Hey there,

We have just migrated our Elastic stack from version 2.3 (4.5 Kibana) to 5.2, and I faced some issues with Kibana authorization. (I don't know if it is Kibana or X-Pack issue.)

I know that Kibana doesn't support object level (search, visualization, dashboard, ...) access control, but in the previous version we managed to solve this by using document level security on the .kibana index. I created a separate role for each user group, and it looked something like this:

PUT /_shield/role/MyRole
{
  "indices": [ 
    {
      "names": [ ".kibana*" ], 
      "privileges": ["view_index_metadata"]
    },
    {
      "names": [ ".kibana*" ], 
      "privileges": ["read"],
      "query": {
                  "bool": {
                    "should": [
                      {"regexp": {"_uid": {"value": "config.*"}}},
                      {"regexp": {"_uid": {"value": "index-pattern.*myindex-.*"}}}
                    ]
                  }
                }
    },
    {
      "names": [ ".kibana*" ], 
      "privileges": ["read"],
      "query": {"regexp": {"title": {"value": "myrole.*"}}}
    },
    {
      "names": [ "myindex-*" ], 
      "privileges": ["read","view_index_metadata"]
    }
  ]
}

The users could log in to Kibana (view_index_metadata on .kibana and the access to the config document grants it), browse the "myindex-" indices throught "myindex-" index pattern, and view the objects with "myrole" prefix.
In Kibana 4.5 it worked perfectly. Now we moved to 5.2 and if a member of this role logs in, it can see every object.

A managed to narrow down the problem. It seems that if I add "read" access to the .kibana index, it completely ignores the "query" part. However document level security works fine on all other indices.

Anyone faced the same issue? Is it an intentional behavior or is it a bug?

Thanks,
Peter

2

Hi @peter.ridzi,

[edit: the following two sentences are incorrect, see comments below]
in Kibana 5.x the objects stored in the .kibana index are always accessed using the user specified in elasticsearch.username. That is why the permissions assigned to the logged-in user do not take effect.

Implementing full security on the saved object level is something that is planned. The currently recommended workaround for multi-tenant Kibana setups is to run multiple Kibana instances with different kibana.index settings.

3

Hi @weltenwort,

Thank you for your response.
I understand your point here, but that means every user has the same privileges in kibana (if the technical user has write access to .kibana, than every user could save objects). But it is not the way it works right now.

I already have users who can save objects, while others can't. It depends on their (logged-in user) permissions to .kibana. A user with only the role in my example can't save object, just read them. If I try to save a search using it, I get the following:
Discover: Request to Elasticsearch failed: "[security_exception] action [indices:data/write/index] is unauthorized for user [testuser]"

This is great for me, I expect this behavior. My experience is that Kibana 5.2 ignores the "query" part (and and nothing else). (In 4.5 it worked too.)

We would like to avoid running different Kibana instances parallely. Do you know any way to make Kibana use the document level security? Am I missing something here? (We were satisfied in the previous version as an interim solution.)

Thanks,
Peter

4

This is a common misconception, but it is not accurate. The user specified in the kibana.yml configuration is only used for internal requests to the .kibana index that are not initiated by any given end-user, whereas the vast majority of requests are initiated by an end-user, and those are always authenticated as the current end-user regardless of which proxy/index they run against. Document level security should technically be possible against Kibana for read-only users, though we don't have an officially supported option for it.

Are you assigning any other roles to the users besides MyRole, perhaps the built-in kibana_user role? Permissions across roles are OR'd, so you can effectively override the restrictions from one role if another role is more permissive.

5

Thank you for reminding me. I was aware of that. This is the only role assigned to the user.

The view_index_metadata and read access to the config doc is enough to log into Kibana, so I didn't use the kibana_user role at all.

6

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