Action indices:data/read/mget is unauthorized but privilege listed

Elastic Stack Elasticsearch
1

Hi I have a user who's been given the privilege "indices:data/read/mget" but is receiving the error "ElasticSearchSecurityException[action [indices:data/read/mget] is unauthorized for user ..." What am I doing wrong?

username:
  cluster:
      - cluster:monitor/nodes/info
      - cluster:monitor/health
  indices:
      'logstash-systemname-*':
       privileges:indices:admin/mappings/fields/get, indices:admin/validate/query, indices:admin/get,indices:data/read/mget,indices:data/read/get, read, search, indices:data/read/msearch
2

Hi,

I wonder if maybe the formatting of the role is an issue? Do you see any log messages when you start up about an invalid role?

Maybe try this:

username:
  cluster:
      - cluster:monitor/nodes/info
      - cluster:monitor/health
  indices:
      'logstash-systemname-*':
        privileges:
          - indices:admin/mappings/fields/get
          - indices:admin/validate/query
          - indices:admin/get
          - read

Just a note, I removed search and individual data read actions as they should already be covered by the read privilege. If this doesn't work, can you share the request that is failing along with the log message? Also, what type of user authentication and role assignment are you using?

3

So I think that reformatting got me further. I gave the user a link to a dashboard I created for him and he logged in but there was an error reported at the screen top. I've seen it before where an error can prevent the dashboard from rendering. He saw the layout but there was no data. The error was an index_not_found_exception for an index he doesn't have access to.

Someone else set up the LDAP authorization realm and I'm not sure why he's granting admin privileges. What would you recommend for cluster and indices privileges for a user who needs to view an index pattern I create, and view and create visualizations and dashboards based on that pattern?

4

I've removed one of my colleagues from our admin security group and am trying to grant him access to an index. I have in roles.yml:

username:
  indices:
    'logstash-systemname-*'
       privileges:
         - read

I sent him the URL to the dashboard and he's getting this error:

Visualize: [security_exception] action [indices:data/read/msearch] is unauthorized for user ...

What am I missing?

5

Hey Craig,

I suggest starting with the built-in Kibana4 user role, and creating new role based on it. Instead of granting the privileges to "*", you can grant it to a specific subset of indexes:

# The required permissions for kibana 4 users.
kibana4:
  cluster: 
      - cluster:monitor/nodes/info
      - cluster:monitor/health 
  indices:
    '*':
      privileges: 
       - indices:admin/mappings/fields/get
       - indices:admin/validate/query
       - indices:data/read/search
       - indices:data/read/msearch
       - indices:data/read/field_stats
       - indices:admin/get
    '.kibana':
      privileges: indices:admin/exists, indices:admin/mapping/put, indices:admin/mappings/fields/get, indices:admin/refresh, indices:admin/validate/query, indices:data/read/get, indices:data/read/mget, indices:data/read/search, indices:data/write/delete, indices:data/write/index, indices:data/write/update
6

Hi Steve. I created a roles.yml entry just like you listed for cdfoote role with 'logstash-systemname-*' instead of '*' as you suggested. I cleared my browser cache and went to the dashboard with visualizations created on that index pattern but I'm still getting the error:

Visualize: [security_exception] action [indices:data/read/msearch] is unauthorized for user [cdfoote]

Any ideas?

7

Did you add the role to the user?

If cdfoote is part of the esusers, you can run:

bin/shield/esusers roles cdfoote

to see what roles are assigned to that user, and make sure that your new role is properly assigned.

8

We're connected to LDAP so I have an entry in role_mapping.yml:

cdfoote: [
     "uid=cdfoote,ou=People,ou=..."
        ]

I've touched both files and see them updated in the log so I'm pretty sure they're being read. What I'm not sure of is the rest of the files' content. Someone else configured them and I'm wondering if a white-space problem is causing my section to not be read.

9

Hi Craig,

Are you sure the role is being mapped properly? If you grant access to * does the role work? If not, the role may not be mapped properly. You can also turn the log level up to TRACE and see what roles are being mapped.

10

Hi Jay, I change the index pattern filter to * and I could see everything. I then changed it back again and I'm getting the same error:

Visualize: [security_exception] action [indices:data/read/msearch] is unauthorized for user [cdfoote]

What exactly would I change to turn on TRACE logging?

11

I modified the logging.yml, sibling to roles.yml, changing INFO to TRACE and monitored the logs but saw no trace entries. Do I need to restart elasticsearch? The access log was very busy and had numerous entries with my name: a bunch of granted for all the privileges except for the one in question which was denied.

12

You can also turn the log level up to TRACE and see what roles are being mapped.

What exactly do I need to do to see what roles are being mapped?

13

Hi Craig,

Sorry for the delay. In your CONFIG_DIR/logging.yml, add shield: TRACE under the logger: section. The logging.yml file you mentioned in a previous post is only for the audit logs.

14

Ok, got it thanks.

Now when I log in I get:

[timestamp][DEBUG][shield.authc.support ] [servername] the roles [[cdfoote]], are mapped from the user [ldap] for realm [uid=cdfoote,...]
[timestamp][DEBUG][shield.authc.esusers ] [servername] user not found in cache, proceeding with normal authentication
[timestamp][DEBUG][shield.authc.ldap    ] [servername] authenticated user [cdfoote], with roles [[cdfoote]]
[timestamp][INFO ]rest.suppressed       ] /_msearch Params: {ignore unavailable=true, preference=#, timeout=0}
ElasticsearchSecurityException[action [indices:data/read/msearch] is unauthorized for user [cdfoote]]

Additionally I've moved my blocks from the bottoms to the tops of both role_mapping.yml and roles.yml.

It looks to me like the role mapping is working correctly, assigning my user account to the cdfoote role to which I've given the same privileges as the kibana4 role, including "indices:data/read/msearch". If I set the indices filter to *, everything works, but when I set it to the desired systemname, I'm consistently getting this error. I'm at a loss, any ideas?

15

I believe you mentioned that you have audit logging enabled, is that correct? If so when you make a request that causes the exception can you grab the access_denied audit entry?

16

Questions about editing shield's config files.

  • In role_mapping.yml, it seems you can use two syntaxes:
 cdfoote:
   - "uid=cdfoote,..."

or:

cdfoote: [
  "uid=cdfoote,..."
    ]

Are they compatible within the one file or do you need to use one or the other?

  • In roles.yml, similarly you can set privileges two ways:

privileges: indices:admin/mappings/fields/get, admin/get, ...

or:

privileges:
  - indices:admin/mappings/fields/get
  - admin/get
  - ...

Are they compatible within the same file or do you have to choose one or the other?

  • Does the number of spaces indenting child lines need to be consistent? Is two spaces OK?

  • Does the order of the entries make a difference? Can a formatting error somewhere in a file cause earlier entries to work but later entries to fail?

17

You can use a mix of the two in the same file for both.

I would go with consistent and 2 spaces are good.

Ordering should not matter.

The incorrectly formatted entries should be skipped with a log message warning of this and processing of other roles should continue.

18

There are a lot and I cannot copy and paste (non-internet-connected machine). Is there something I should be looking for?

19

What indices are listed that access is being denied to?

20

Actually there weren't that many, poor use of grep was all.
I see 4 access-denied messages for cdfoote, all from transport. Only one shows an index: ".marvel_es-2016.01.04". The action in that message was "indices:data/read/search[phase/query+fetch]".

The others just state the action: "indices:data/read/msearch".

Oh yeah, I am currently getting no parsing errors when I touch both the files.