Allow users with read role to use the async_search/status endpoint #106561
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
quux00
force-pushed
the
async-search-status/permissions-change
branch
from
7a3cca1 to
88a711e
Compare
quux00
changed the title
quux00
added
:Security/Authorization
|
Closed in favor of #106638 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary of issue
Currently, the
async_searchaction andasync_search/statusactions have radically different action names:GetAsyncStatusAction has
cluster:monitor/async_search/statusGetAsyncSearchAction has
indices:data/read/async_search/getThe status endpoint requires the monitor, manage or all privileges, which is not something all Kibana users will have, which results in this error on a secured cluster:
The async_search/status endpoint was added in this PR: #62947
The original request for this endpoint came from Kibana (#57537) and their scope was to have background jobs running to check on status, using the kibana_admin user, so that is likely why a
cluster:monitoraction name was chosen rather thanindices:data.However, there are two arguments for changing this:
If you have the privilege to start an async search and retrieve its results, you should also have the permissions to check its status.
Cross-cluster async search has recently made a change to do incremental merges of search results whenever a user requests them via the
GET _async_search/:idendpoint. This will have CPU cost, and since Kibana regularly polls this endpoint to check for status, we (Elasticsearch) have asked Kibana to move to polling status via_async_search/status. The current permissions settings on the status endpoint now blocks that move.Options for changing
cluster:monitor/async_search/statusto the IndexPrivilege.READ_AUTOMATON, but that does not work. It still fails with the same security error mentioned above. See the details section below.I also tried adding that to IndexPrivilege.ALL and it also still fails with the same error message. So my guess is that the cluster:monitor prefix is causing some issue.
indices:data/read/async_search/getIs this allowed? Is there a way to make this backwards compatible? We'd need roles with only
manageormonitorand notreadroles to still have access to async-search-status so as not to break existing functionality.Attempt 1: add
cluster:monitor/async_search/statusto the IndexPrivilege.READ_AUTOMATONWith a user having the following privileges:
I can start an async-search no problem (not shown), but when I query for status I get an error, even with the code changes in this first commit where I added
cluster:monitor/async_search/statusto the IndexPrivilege.READ_AUTOMATON.(toggle for error info and stack trace)
What is the best way forward on this issue?