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

CraigFoote · December 22, 2015, 4:39pm

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

jaymode · December 22, 2015, 6:32pm

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?

CraigFoote · December 23, 2015, 2:15pm

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?

CraigFoote · December 23, 2015, 2:58pm

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?

skearns · December 23, 2015, 3:09pm

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

CraigFoote · December 23, 2015, 3:48pm

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?

skearns · December 23, 2015, 4:51pm

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.

CraigFoote · December 23, 2015, 4:58pm

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.

jaymode · December 23, 2015, 7:45pm

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.

CraigFoote · December 23, 2015, 8:13pm

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?

CraigFoote · December 23, 2015, 8:29pm

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.

CraigFoote · January 4, 2016, 5:05pm

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?

jaymode · January 4, 2016, 5:38pm

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.

CraigFoote · January 4, 2016, 6:02pm

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?

jaymode · January 4, 2016, 6:16pm

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?

CraigFoote · January 4, 2016, 6:19pm

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?

jaymode · January 4, 2016, 6:22pm

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.

CraigFoote · January 4, 2016, 6:27pm

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

jaymode · January 4, 2016, 6:28pm

What indices are listed that access is being denied to?

CraigFoote · January 4, 2016, 6:36pm

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.