Skip to content

[Backport] Add more context to cluster access denied messages #68263

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Feb 3, 2021

Conversation

tvernum
Copy link
Contributor

@tvernum tvernum commented Feb 1, 2021

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.

Backport of: #66900

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.

Backport of: elastic#66900
@tvernum
Copy link
Contributor Author

tvernum commented Feb 3, 2021

@elasticmachine update branch

@mark-vieira
Copy link
Contributor

@elasticmachine update branch

@tvernum tvernum merged commit 926eb91 into elastic:7.x Feb 3, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants