# Debugging role-based access control to documents

**URL:** https://discuss.elastic.co/t/debugging-role-based-access-control-to-documents/316628
**Category:** Elasticsearch
**Tags:** elastic-stack-security
**Created:** [October 14, 2022, 11:32am UTC](https://discuss.elastic.co/t/debugging-role-based-access-control-to-documents/316628 "2022-10-14T11:32:54Z")
**Posts on this page:** 5
**Page:** 1

<div class="post-metadata">

### Author: ![foxy](https://avatars.discourse-cdn.com/v4/letter/f/b5ac83/32.png) [@foxy](https://discuss.elastic.co/u/foxy)
#### Post date: [October 14, 2022, 11:32am UTC](https://discuss.elastic.co/t/debugging-role-based-access-control-to-documents/316628/1 "2022-10-14T11:32:54Z")

</div>

Is there a way to see how access to a particular document set has been granted (i.e: where the permission has come from)?

**context**

We have several indices that employ [document level security](https://www.elastic.co/guide/en/elasticsearch/reference/7.17/document-level-security.html) to restrict access, by role, to particular subsets of documents. This enables us to use an access control list to assign users to roles that grant read permissions over subsets of documents in our indices.

Although this has been working well for us previously, when it came time to configure this for a new index and role set, we find that users can see many more documents than they should be able to.

_example where all is as-expected_

**GET /\_security/role/banana\_department\_stockroom**

```json
{
  "banana_department_stockroom" : {
    "cluster" : [],
    "indices" : [
      {
        "names" : [
          "stockroom-reports-*",
          "stockroom-reports"
        ],
        "privileges" : [
          "read",
          "view_index_metadata"
        ],
        "query" : """{"bool":{"filter":[{"term":{"org.unit_code":"banana_department"}}]}}""",
        "allow_restricted_indices" : false
      }
    ],
    "applications" : [/* kibana */],
    "run_as" : [],
    "metadata" : { },
    "transient_metadata" : {
      "enabled" : true
    }
  }
}

```

_non-working example_

**GET /\_security/role/banana\_department\_sales**

```json
{
  "banana_department_sales" : {
    "cluster" : [],
    "indices" : [
      {
        "names" : [
          "sales-reports-*",
          "sales-reports"
        ],
        "privileges" : [
          "read",
          "view_index_metadata"
        ],
        "query" : """{"bool":{"filter":[{"term":{"org.unit_code":"banana_department"}}]}}""",
        "allow_restricted_indices" : false
      }
    ],
    "applications" : [],
    "run_as" : [],
    "metadata" : { },
    "transient_metadata" : {
      "enabled" : true
    }
  }
}

```

In the working example, members of the banana department with the `banana_department_stockroom` role can query the stockroom reports and only see their own data and don't see any data from the other departments; in searches it is as if they were the only department in the whole organisation. In Kibana's logs, we see expected audit events granting access for these queries.

However, in the case of the sales reports index, they can view all the other department's data. Kibana's logs show the same audit events.

I have checked all the other roles of affected users and cannot see any extraneous permissions that would affect this. If I perform a search using the same `query` as above, I see the subset of documents I was expecting.

Any pointers would be greatly appreciated! I am going a little bananas myself trying to figure it out.

Many thanks!

---

<div class="post-metadata">

### Author: ![Yang\_Wang](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/yang_wang/32/48857_2.png) [@Yang\_Wang](https://discuss.elastic.co/u/Yang_Wang)
#### Post date: [October 14, 2022, 12:21pm UTC](https://discuss.elastic.co/t/debugging-role-based-access-control-to-documents/316628/2 "2022-10-14T12:21:41Z")

</div>

Login as one of the sales users and run [GetUserPrivileges](https://www.elastic.co/guide/en/elasticsearch/reference/current/security-api-get-user-privileges.html) API. What do you see? Does it still show document level security for the sales indices? If not, there are other roles granting more permissions.

Also, do you have anonymous access enabled?

---

<div class="post-metadata">

### Author: ![foxy](https://avatars.discourse-cdn.com/v4/letter/f/b5ac83/32.png) [@foxy](https://discuss.elastic.co/u/foxy)
#### Post date: [October 14, 2022, 2:17pm UTC](https://discuss.elastic.co/t/debugging-role-based-access-control-to-documents/316628/3 "2022-10-14T14:17:57Z")

</div>

Hello, thank you very much for your pointers.

- Anonymous access is disabled: users must authenticate. Our load balancer picks a kibana or elasticsearch instance (as appropriate) to farm the request to and sets the `es-security-runas-user` header via its authentication provider. We know this part is working from the audit logs which correctly identify the `user.name` and displays the expected list of roles.

- I used the elasticsearch Python library's `es.security.get_user_privileges()`, which shows me the following output:

```python
{
  'cluster': [],
  'global': [],
  'indices': [
    { 
      'names': [ 'stockroom-reports',
                 'stockroom-reports-*' ],
      'privileges': ['read', 'view_index_metadata'],
      'query': [
        '{"bool":{"filter":[{"term":{"org.unit_code":"banana_department"}}]}}'
      ],
      'allow_restricted_indices': False
    },
    {
      'names': [ 'sales-reports',
                 'sales-reports-*' ],
      'privileges': ['read', 'view_index_metadata'],
      'query': [
        '{"bool":{"filter":[{"term":{"org.unit_code":"banana_department"}}]}}'
      ],
      'allow_restricted_indices': False
    }
  ],
  'applications': [ { 'application': 'kibana-.kibana',
            # snip for brevity
                  } ],
  'run_as': []
}

```

This seems to reflect what I would have expected. What ideally would be helpful is if there was some way of logging or producing an explanation for the role and permission set used to gain access to a particular document or results set in a search. For example, "run as user `bananateam_alice` successful due to the `read` permission inherited from role `banana_department_sales`", or alternatively an "explain permission" API that can be run against an index, so that comparisons can be made between functional and non-functional indices.

---

<div class="post-metadata">

### Author: ![Yang\_Wang](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/yang_wang/32/48857_2.png) [@Yang\_Wang](https://discuss.elastic.co/u/Yang_Wang)
#### Post date: [October 17, 2022, 4:47am UTC](https://discuss.elastic.co/t/debugging-role-based-access-control-to-documents/316628/4 "2022-10-17T04:47:52Z")

</div>

The audit log can show the effective user and its role for every granted action. You can use that to make sure the user and roles are working as expected. Elasticsearch currently does not provide more information about exactly which role and which index permission is used to grant the access.

In your case, I'd suggest reduce the number of variables. Maybe start with a new user, grant it a single role that has a single index privileges, e.g.:

```auto
PUT _security/role/foo-role
{
  "indices": [
    {
      "names": [
        "sales-reports"
      ],
      "privileges": [
        "read"
      ],
      'query': [
        '{"bool":{"filter":[{"term":{"org.unit_code":"banana_department"}}]}}'
      ]
    }
  ]
}

PUT _security/user/foo
{"password":"password","roles":["foo-role"]}

```

And see if permissions work correctly for the new user `foo`. This should help narrowing down the problem.

---

<div class="post-metadata">

### Author: ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)
#### Post date: [November 14, 2022, 4:47am UTC](https://discuss.elastic.co/t/debugging-role-based-access-control-to-documents/316628/5 "2022-11-14T04:47:59Z")

</div>

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