# Kibana 5.2 ignores document level security on .kibana
**URL:** https://discuss.elastic.co/t/kibana-5-2-ignores-document-level-security-on-kibana/85130
**Category:** Kibana
**Created:** [May 9, 2017, 4:30pm UTC](https://discuss.elastic.co/t/kibana-5-2-ignores-document-level-security-on-kibana/85130 "2017-05-09T16:30:04Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@peter.ridzi](https://discuss.elastic.co/u/peter.ridzi)
#### Post date: [May 9, 2017, 4:30pm UTC](https://discuss.elastic.co/t/kibana-5-2-ignores-document-level-security-on-kibana/85130/1 "2017-05-09T16:30:04Z")
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
---
### Author:  [@weltenwort](https://discuss.elastic.co/u/weltenwort)
#### Post date: [May 10, 2017, 9:59am UTC](https://discuss.elastic.co/t/kibana-5-2-ignores-document-level-security-on-kibana/85130/2 "2017-05-10T09:59:13Z")
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](https://github.com/elastic/kibana/issues/4453). The currently recommended workaround for multi-tenant Kibana setups is to run multiple Kibana instances with different `kibana.index` settings.
---
### Author:  [@peter.ridzi](https://discuss.elastic.co/u/peter.ridzi)
#### Post date: [May 10, 2017, 12:17pm UTC](https://discuss.elastic.co/t/kibana-5-2-ignores-document-level-security-on-kibana/85130/3 "2017-05-10T12:17:31Z")
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
---
### Author:  [@Court](https://discuss.elastic.co/u/Court)
#### Post date: [May 10, 2017, 2:44pm UTC](https://discuss.elastic.co/t/kibana-5-2-ignores-document-level-security-on-kibana/85130/4 "2017-05-10T14:44:38Z")
> [@weltenwort](#):
>
> in Kibana 5.x the objects stored in the .kibana index are always accessed using the user specified in elasticsearch.username
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.
---
### Author:  [@peter.ridzi](https://discuss.elastic.co/u/peter.ridzi)
#### Post date: [May 10, 2017, 3:01pm UTC](https://discuss.elastic.co/t/kibana-5-2-ignores-document-level-security-on-kibana/85130/5 "2017-05-10T15:01:19Z")
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.
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [June 7, 2017, 3:07pm UTC](https://discuss.elastic.co/t/kibana-5-2-ignores-document-level-security-on-kibana/85130/6 "2017-06-07T15:07:57Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.