Understanding permissions for a request

Search Guard
1
  • 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

2

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.

···

Am 20.03.2019 um 22:58 schrieb Fred Drake <fdrake@gmail.com>:

* 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

--
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+unsubscribe@googlegroups.com.
To post to this group, send email to search-guard@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\.

3

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:

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

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

4

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

···

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

5

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 deal with this? We’re just letting the search contexts from scrolls time out now, but we’d like to be able to clear them as soon as they’re no longer needed.

6

When running into permission errors for a particular role, I suggest to follow this troubleshooting guide on how to debug permission problems:

If SG returns a 403 for a particular request, you should find a corresponding entry in the log files, stating which permission is missing for which role and index.

You also might want to set the log level to a least WARN to see the error in the logs: