Authorization denial errors are not actionable #42166

tvernum · 2019-05-16T02:14:27Z

The access denied error message is:

action [{}] is unauthorized for user [{}]

This has a few problems:

In the case of an index level action, it doesn't tell you which index was denied.
It doesn't list the user's roles
We discourage security administrators from assigning raw actions to roles, but that is the only information that is provided in the error.

When users run into these errors they aren't being given enough information to be able to solve the problem. We need to be more explicit about exactly what was rejected and the options to resolve it.

One idea was to include a list of the cluster/index privileges that would grant this action (perhaps roughly sorted from least-privilege to most-privileged)

The text was updated successfully, but these errors were encountered:

elasticmachine · 2019-05-16T02:14:29Z

Pinging @elastic/es-security

Access denied messages for indices were overly brief and missed two pieces of useful information: 1. The names of the indices for which access was denied 2. The privileges that could be used to grant that access This change improves the access denied messages for index based actions by adding the index and privilege names. Privilege names are listed in order from least-privilege to most-privileged so that the first recommended path to resolution is also the lowest privilege change. Relates: elastic#42166

Access denied messages for indices were overly brief and missed two pieces of useful information: 1. The names of the indices for which access was denied 2. The privileges that could be used to grant that access This change improves the access denied messages for index based actions by adding the index and privilege names. Privilege names are listed in order from least-privilege to most-privileged so that the first recommended path to resolution is also the lowest privilege change. Relates: #42166

Access denied messages for indices were overly brief and missed two pieces of useful information: 1. The names of the indices for which access was denied 2. The privileges that could be used to grant that access This change improves the access denied messages for index based actions by adding the index and privilege names. Privilege names are listed in order from least-privilege to most-privileged so that the first recommended path to resolution is also the lowest privilege change. Relates: elastic#42166 Backport of: elastic#60357

In elastic#60357 we improved the error message when access to perform an action on an index was denied by including the index name and the privileges that would grant the action. This commit extends the second part of that change (the list of privileges that would resolve the problem) to situations when a cluster action is denied. This implementation for cluster privileges is slightly more complex than that of index privileges because cluster privileges can be dependent on parameters in the request, not just the action name. For example, "manage_own_api_key" should be suggested as a matching privilege when a user attempts to create an API key, or delete their own API key, but should not be suggested when that same user attempts to delete another user's API key. Relates: elastic#42166

In #60357 we improved the error message when access to perform an action on an index was denied by including the index name and the privileges that would grant the action. This commit extends the second part of that change (the list of privileges that would resolve the problem) to situations when a cluster action is denied. This implementation for cluster privileges is slightly more complex than that of index privileges because cluster privileges can be dependent on parameters in the request, not just the action name. For example, "manage_own_api_key" should be suggested as a matching privilege when a user attempts to create an API key, or delete their own API key, but should not be suggested when that same user attempts to delete another user's API key. Relates: #42166

This commit adds a User's list of current role names to access denied error messages to aid in diagnostics. This allows an administrator to know whether the correct course of action is to add another role to the user (e.g. by fixing incorrect role mappings) or by modifying a role to add more privileges. Resolves: elastic#42166

This commit adds a User's list of current role names to access denied error messages to aid in diagnostics. This allows an administrator to know whether the correct course of action is to add another role to the user (e.g. by fixing incorrect role mappings) or by modifying a role to add more privileges. Resolves: #42166

Our authorization engine has a short-circuit check for the intended action the takes place before resolving index names (wildcards). That is, a requests like GET /_search GET /logs-*/_search GET /logs-20210414/_search will fail fast if the user does not have read permission on any indices, and we will never resolve the list of indices that the request targets. Consequently, it is impossible to provide the list of denied indices in the error message because that list does exist (and, in the case of wildards would be empty even if we did resolve it). This change updates the access denied message so that it does not attempt to include the list of indices if the IndiceAccessControl object has an empty list of denied indices. Prior to this, we would generate messages such as action [indices:data/read/search] is unauthorized for user [test] with roles [test] on indices [], That "indices []" section is never useful since it does not name any indices, so it has now been dropped from the message if it is empty. Relates: elastic#42166, elastic#60357

Our authorization engine has a short-circuit check for the intended action the takes place before resolving index names (wildcards). That is, a requests like GET /_search GET /logs-*/_search GET /logs-20210414/_search will fail fast if the user does not have read permission on any indices, and we will never resolve the list of indices that the request targets. Consequently, it is impossible to provide the list of denied indices in the error message because that list does exist (and, in the case of wildards would be empty even if we did resolve it). This change updates the access denied message so that it does not attempt to include the list of indices if the IndicesAccessControl object has an empty list of denied indices. Prior to this, we would generate messages such as action [indices:data/read/search] is unauthorized for user [test] with roles [test] on indices [], That "indices []" section is never useful since it does not name any indices, so it has now been dropped from the message if it is empty. Relates: #42166, #60357

Our authorization engine has a short-circuit check for the intended action the takes place before resolving index names (wildcards). That is, a requests like GET /_search GET /logs-*/_search GET /logs-20210414/_search will fail fast if the user does not have read permission on any indices, and we will never resolve the list of indices that the request targets. Consequently, it is impossible to provide the list of denied indices in the error message because that list does not exist (and, in the case of wildards would be empty even if we did resolve it). This change updates the access denied message so that it does not attempt to include the list of indices if the IndicesAccessControl object has an empty list of denied indices. Prior to this, we would generate messages such as action [indices:data/read/search] is unauthorized for user [test] with roles [test] on indices [], That "indices []" section is never useful since it does not name any indices, so it has now been dropped from the message if it is empty. Relates: elastic#42166, elastic#60357 Backport of: elastic#71715

tvernum added >enhancement :Security/Authorization Roles, Privileges, DLS/FLS, RBAC/ABAC labels May 16, 2019

tvernum mentioned this issue May 16, 2019

Document which APIs are affected by which role pivileges #37538

Closed

tvernum self-assigned this Jun 3, 2019

jkakavas mentioned this issue Jul 30, 2019

Improve accessibility for privileges and action unauthorized messages. #44984

Closed

rjernst added the Team:Security Meta label for security team label May 4, 2020

tvernum mentioned this issue Jul 29, 2020

Add more context to index access denied errors #60357

Merged

Mpdreamz mentioned this issue Nov 16, 2020

7.10.1 Meta Ticket elastic/elasticsearch-net#5096

Closed

61 tasks

stevejgordon mentioned this issue Dec 17, 2020

7.11.0 Meta Ticket elastic/elasticsearch-net#5198

Closed

tvernum mentioned this issue Dec 31, 2020

Add more context to cluster access denied messages #66900

Merged

tvernum mentioned this issue Jan 31, 2021

Auth error for index template APIs doesn't include manage_index_templates cluster priv #68144

Closed

tvernum mentioned this issue Feb 22, 2021

Include role names in access denied errors #69318

Merged

tvernum closed this as completed in #69318 Mar 10, 2021

tvernum mentioned this issue Apr 15, 2021

In access deny msg, only show indices if resolved #71715

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Authorization denial errors are not actionable #42166

Authorization denial errors are not actionable #42166

tvernum commented May 16, 2019

elasticmachine commented May 16, 2019

Authorization denial errors are not actionable #42166

Authorization denial errors are not actionable #42166

Comments

tvernum commented May 16, 2019

elasticmachine commented May 16, 2019