Document level security query causing error/no data

Elastic Stack Elasticsearch
1

I'm following the docs here https://www.elastic.co/guide/en/x-pack/6.1/field-and-document-access-control.html#document-level-security

And I've set up a role and a user as shown in the screenshots below.

I think I originally did something wrong because when I logged in as that user and went to the Kibana/Discover page I got a Error 400 Bad Request: [parse_exception] Failed to derive xcontent However, since changing to what you see in the screenshots when I login the user sees no data at all.

Any ideas why? The user should see at least 2 other documents that have the name not of Tom Cruise. I've also included a screenshot that shows the query I put in the role works in the console tool.

Thanks

role
Screen Shot 2018-01-11 at 16.41.30.png1163×770 39.9 KB

user
Screen Shot 2018-01-11 at 16.41.39.png1217×491 18.9 KB

search
Screen Shot 2018-01-11 at 16.41.50.png1516×705 85.3 KB

2

Hello Jonathan,

Hoping I didn't misunderstand your question :

You seem to have set a role tomcruiserole with read privileges on {"term" :{"name.keyword":"Tom Cruise"}}, and a user with that role.

Why would you expect a user with just this role to read documents that do not match your Granted Documents Query ?

The user should see at least 2 other documents that have the name not of Tom Cruise

(emphasis mine)

3

Thanks for the reply.

I expect that as this is what the docs say:

For example, the following role grants read access to all indices, but restricts access to documents whose department_id equals 12.

{
  "indices" : [
    {
      "names" : [ "*" ],
      "privileges" : [ "read" ],
      "query" : {
        "term" : { "department_id" : 12 }
      }
    }
  ]
}

Therefore it restricts documents to id 12 then I'd expect them to see 11 and 13?

4

Even if the opposite is true ie/ it should only see documents with Tom Cruise, I do not see this, the user sees no documents at all

5

OK I have it working in the opposite manor than the docs say. It is now returning data. The issue was the "Optional" granted fields box. It was blank and it needed to be *. Can I suggest if it's optional that * is applied if not entered into that box? Thanks

6

Restricts has the meaning of limits in that sentence. That is, this role gives read permission to the documents that match the query, not the other way around. I'll make sure we revisit the wording of that sentence to make it less ambiguous.

This is where Field Level Security comes into place. You have removed all Granted Fields from the role definition ( * is the default ), this is why you don't see any documents

7

Great that it's working for you now.

* is the default value for that field when one opens the new Role definition. If someone removes it while adding the role definition, the assumption is that it is on purpose.

8

Ok thanks, must have missed that. However when you put the cursor into that box and you get intellisense for the fields * is not in the dropdown. I think it should be to give the user the hint that it can be selected to mean all fields

9

@ikakavas is there any tips on how to create/edit roles on the Granted Documents Query? Whenever I paste queries and then login as a user I always seem to get Discover: Failed to derive xcontent It's definitely down to json escaping etc.

For example using the dev tools this is successful but the user gets the xcontent error when loggedin:

PUT /_xpack/security/role/TomCruiseRole
{
    "cluster": [
      "all"
    ],
    "indices": [
      {
        "names": [
          "customer*"
        ],
        "privileges": [
          "read"
        ],
        "field_security": {
          "grant": [
            "*"
          ]
        },
        "query": "\"bool\":{\"must_not\": [{\"term\": {\"name.keyword\": \"Tom Cruise\"}}]}"
      }
    ],
    "run_as": [],
    "metadata": {},
    "transient_metadata": {
      "enabled": true
    }
}
10

Turns out I needed {} around the value of query

11

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