Understanding permissions for a request

[Fred Drake]

* Using SG and Elasticsearch 6.5.3 with JRE 8 on Ubuntu Linux 18.04

The documentation, under, "Expert: Role Mapping Modes", tells me:

By default, Search Guard maps every incoming request to a Search Guard role by mapping the user name, the backend roles and/or the hostname to one or more Search Guard roles. This is configured in roles mapping configuration.

The number mismatch between "maps every incoming request to a Search Guard role" and "to one or more Search Guard roles" is confusing.

I have an index with two roles defined, one for readers and one for modifiers.  Modifiers are expected to also be readers.  When an incoming request comes in from a user mapped to both of these roles, does the request get the union of the permissions granted by these roles?

This should probably be made explicit in the documentation.

  -Fred

[SG]

Yes, the request gets the union of the permissions granted by these roles.

We will made this more clear in the docs, thx for your suggestion.

> --
> You received this message because you are subscribed to the Google Groups "Search Guard Community Forum" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to search-guard...@googlegroups.com.
> To post to this group, send email to search...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/74005308-07c5-4862-a449-dde3315deb99%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Fred Drake]

On Thursday, March 21, 2019 at 2:21:43 AM UTC-4, Search Guard wrote:

Yes, the request gets the union of the permissions granted by these roles.

Thank you for responding quickly!  Understanding how other people think about these things is often challenging.

We will made this more clear in the docs, thx for your suggestion.

I definitely appreciate documentation improvements.

So I've spent some more time trying to track down the problem Wyllys started to bring up yesterday.

I'm creating a new index, roles, and role mappings, all as an administrative user:

PUT /fd-sp-57feef3fb471-f4634ddd017a
{...}


PATCH /_searchguard/api/roles
[{'op': 'add',
  'path': '/fd-sp-57feef3fb471-f4634ddd017a-reader',
  'value': {'cluster': ['CLUSTER_COMPOSITE_OPS_RO'],
            'indices': {'fd-sp-57feef3fb471-f4634ddd017a': {'*': ['READ',
                                                                  'SEARCH']}}}},
 {'op': 'add',
  'path': '/fd-sp-57feef3fb471-f4634ddd017a-modifier',
  'value': {'cluster': ['CLUSTER_COMPOSITE_OPS'],
            'indices': {'fd-sp-57feef3fb471-f4634ddd017a': {'*': ['INDICES_ALL']}}}}]


PATCH /_searchguard/api/rolesmapping

[{'op': 'add',
  'path': '/fd-sp-57feef3fb471-f4634ddd017a-reader',
  'value': {'backendroles': [], 'hosts': ['*'], 'users': []}},
 {'op': 'add',
  'path': '/fd-sp-57feef3fb471-f4634ddd017a-modifier',
  'value': {'backendroles': [], 'hosts': ['*'], 'users': []}}]

I then add a user to both role mappings:

PATCH /_searchguard/api/rolesmapping/fd-sp-57feef3fb471-f4634ddd017a-reader
[{'op': 'add',
  'path': '/users/-',
  'value': 'b900c1bd-531b-484f-8e41-e52ee3486740'}]


PATCH /_searchguard/api/rolesmapping/fd-sp-57feef3fb471-f4634ddd017a-modifier

[{'op': 'add',
  'path': '/users/-',
  'value': 'b900c1bd-531b-484f-8e41-e52ee3486740'}]

Using /_bulk to load data into this index then fails with a 403 Forbidden response bearing this message:

no permissions for [indices:admin/refresh] and User [name=b900c1bd-531b-484f-8e41-e52ee3486740, roles=[], requestedTenant=null]

Since INDICES_ALL is defined as indices:*, I'd think that permission would be included for that index.  I've tried adding that explicitly in defined "modifier" role, both for the cluster and the specific index, but that doesn't seem to have an impact.

One interesting note:  The SG dashboard in Kibana shows a warning for the two role mappings: "No corresponding Search Guard role for mapping 'fd-sp-...' found. Click to create it."  The roles are shown when I look at the role definitions, though.  The roles are created before the role mappings, as shown above.

As before:

[Fred Drake]

On Thursday, March 21, 2019 at 10:40:27 AM UTC-4, Fred Drake wrote:

Using /_bulk to load data into this index then fails with a 403 Forbidden response bearing this message:

no permissions for [indices:admin/refresh] and User [name=b900c1bd-531b-484f-8e41-e52ee3486740, roles=[], requestedTenant=null]

Chased this down: This was because we were using refresh without specifying the index, so it was attempting to refresh indexes the user did not have permissions for.  We can specify the index, so that's easy to fix.

We eventually end up running into another issue, where we're searching with the scroll API, and get a 403 Forbidden when clearing the scroll (permission indices:data/read/scroll/clear).  My reading of the ES API is that we're not supposed to specify an index for /_search/scroll, since the relevant indexes are known to the scroll in ES.

Any suggestions on how to address this?

One interesting note:  The SG dashboard in Kibana shows a warning for the two role mappings: "No corresponding Search Guard role for mapping 'fd-sp-...' found. Click to create it."  The roles are shown when I look at the role definitions, though.  The roles are created before the role mappings, as shown above.

As before:
* Using SG and Elasticsearch 6.5.3 with JRE 8 on Ubuntu Linux 18.04

We'd still like to understand this as well.

  -Fred 

[SG]

Search Guard Community Forum - We are moving!

We are moving the Search Guard Community Forum to a new home:
https://forum.search-guard.com/

All content hosted has been migrated to the new forum.

Starting from 2019/03/30 please ask your questions on https://forum.search-guard.com/ only.

The Google Group forum will not be maintained anymore.
Thanks!

> --
> You received this message because you are subscribed to the Google Groups "Search Guard Community Forum" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to search-guard...@googlegroups.com.
> To post to this group, send email to search...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/59121822-0a4c-41d7-9417-0a48be070e6d%40googlegroups.com.