Permissions issue when using _search/scroll and clear

Elasticsearch 7.4.0
Search Guard 7.4.0

I have a user with the SGS_INDEX_ALL role for a given index. When I attempt to clear a scroll context, I get permission denied. It only seems to happen when attempting to clear a scroll context, the scroll request itself works (up until we hit the 500 item limit).

Do we need to assign additional permissions or do some other configuration change to enable the correct permissions to clear a scroll context?

More info from the log:

2019-10-17 11:05:54.357 INFO elasticsearch GET https://XXXX/403cfe70493d-0e5fc9ffc6b5/_search [status:200 request:0.024s]
2019-10-17 11:05:54.363 INFO elasticsearch GET https://XXXX/403cfe70493d-0e5fc9ffc6b5/_search?scroll=5m&size=1000 [status:200 request:0.005s]
2019-10-17 11:05:54.411 WARNING elasticsearch DELETE https://XXXX/_search/scroll [status:403 request:0.048s]

elasticsearch.exceptions.AuthorizationException: AuthorizationException(403, ‘security_exception’, ‘no permissions for [indices:data/read/scroll/clear] and User [name=36b46947-e27f-4423-9d82-98c1fc0cc660, backend_roles=, requestedTenant=null]’)

There is no built-in role called SGS_INDEX_ALL. Maybe you are referring to the action group called SGS_INDICES_ALL?

All built-in action groups:

built-in roles:

The SGS_INDICES_ALL action group grants permission to indices:* so it also includes scroll requests.

Yes, SGS_INDICES_ALL is what I meant (I mis-typed). So I don’t understand the security exception error if the user is assigned a role that has that action group.

Can you please post your role definition here?

Also, can you please visit with the authinfo endpoint with the user in question and post the results?

This prints information about the user and it’s SG roles in JSON.

In the ES log file you should also see some more information as mentioned here:

This should reveil more details about why this is happening. Do you see anything like:

[c.f.s.p.PrivilegesEvaluator] No index-level perm match for 
User [name=..., roles=[...], requestedTenant=null] 
Resolved [aliases=[], indices=[...],
allIndices=[...], types=[*], isAll()=false, isEmpty()=false] 
[Action [indices:data/read/search]] 
[RolesChecked [...]]

We use JWT tokens for auth, but here is result of authinfo query using a valid token:

{
“user” : “User [name=36b46947-e27f-4423-9d82-98c1fc0cc660, backend_roles=, requestedTenant=null]”,
“user_name” : “36b46947-e27f-4423-9d82-98c1fc0cc660”,
“user_requested_tenant” : null,
“remote_address” : “10.14.250.35:52513”,
“backend_roles” : ,
“custom_attribute_names” : [
“attr.jwt.iss”,
“attr.jwt.session_state”,
“attr.jwt.typ”,
“attr.jwt.auth_time”,
“attr.jwt.email_verified”,
“attr.jwt.preferred_username”,
“attr.jwt.given_name”,
“attr.jwt.aud”,
“attr.jwt.acr”,
“attr.jwt.nbf”,
“attr.jwt.resource_access”,
“attr.jwt.ki-realm-roles”,
“attr.jwt.realm_access”,
“attr.jwt.azp”,
“attr.jwt.family_name”,
“attr.jwt.scope”,
“attr.jwt.sub”,
“attr.jwt.name”,
“attr.jwt.exp”,
“attr.jwt.iat”,
“attr.jwt.jti”,
“attr.jwt.email”
],
“sg_roles” : [
“SGS_OWN_INDEX”,
“user-roles-36b46947-e27f-4423-9d82-98c1fc0cc660”
],
“sg_tenants” : {
“36b46947-e27f-4423-9d82-98c1fc0cc660” : true
},
“principal” : null,
“peer_certificates” : “0”,
“sso_logout_url” : null
}

The error from the elastic log:

[2019-10-17T11:05:54,412][INFO ][c.f.s.p.PrivilegesEvaluator] [ktelastic] No cluster-level perm match for User [name=36b46947-e27f-4423-9d82-98c1fc0cc660, backend_roles=, requestedTenant=null] Resolved [aliases=[], indices=[], allIndices=[], types=[], originalRequested=, remoteIndices=] [Action [indices:data/read/scroll/clear]] [RolesChecked [user-roles-36b46947-e27f-4423-9d82-98c1fc0cc660, SGS_OWN_INDEX]]

[2019-10-17T11:05:54,412][INFO ][c.f.s.p.PrivilegesEvaluator] [ktelastic] No permissions for [indices:data/read/scroll/clear]

The roles checked have an action group called “INDICES_ALL”:

{
“user-roles-36b46947-e27f-4423-9d82-98c1fc0cc660” : {
“reserved” : false,
“hidden” : false,
“cluster_permissions” : [
“CLUSTER_COMPOSITE_OPS”
],
“index_permissions” : [
{
“index_patterns” : [
“d20e21af9d20-006e15f6efc3”
],
“fls” : ,
“masked_fields” : ,
“allowed_actions” : [
“INDICES_ALL”,
“SGS_INDICES_ALL”
]
},
{
“index_patterns” : [
“51b5672da2b2-1f2d0781ef09”
],
“fls” : ,
“masked_fields” : ,
“allowed_actions” : [
“INDICES_ALL”
]
}
],
“tenant_permissions” : ,
“static” : false
}
}

Action group “INDICES_ALL” includes SGS_INDICES_ALL (I also manually added indices:data/read/scroll/* just to be safe, but it makes no difference as expected).

{
“INDICES_ALL” : {
“reserved” : false,
“hidden” : false,
“allowed_actions” : [
“indices:data/read/scroll”,
“indices:data/read/scroll/clear”,
“SGS_INDICES_ALL”
],
“type” : “index”,
“static” : false
}
}

Thanks for the infos, that helps! The problem here is that the scroll permission seems to require an additional permission cluster level. You can see it here in the log output:

2019-10-17T11:05:54,412][INFO ][c.f.s.p.PrivilegesEvaluator] [ktelastic] No **cluster-level** perm match for User [name=36b46947-e27f-4423-9d82-98c1fc0cc660, ...

To fix that, add the following permission in the cluster_permissions section:

indices:data/read/scroll*

Also, we will investigate why this permission is required on cluster level, seems a bit unintuitive to me.

Maybe because the /scroll/clear API does not take in index in the URI, its embedded in the body of the post?

Yes, that might be reason, good point :slight_smile:

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