Failure store access - selector-aware role building #122715
Merged
Conversation
This file contains hidden or 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
|
Warning It looks like this PR modifies one or more |
|
Warning It looks like this PR modifies one or more |
|
Warning It looks like this PR modifies one or more |
|
Warning It looks like this PR modifies one or more |
n1v0lg
added
the
auto-merge-without-approval
n1v0lg
removed
the
auto-merge-without-approval
💔 Backport failed
You can use sqren/backport to manually backport by running |
georgewallace
pushed a commit
to georgewallace/elasticsearch
that referenced
this pull request
Mar 11, 2025
This PR adds the `read_failure_store` index privilege and extends the role building logic to support selector-aware authorization. Note that this PR only concerns building roles; the actual authorization logic implementation will follow in a separate PR. The overall approach is based on the proof-of-concept PR (elastic#122007). The purpose of the `read_failure_store` index privilege is to support granting selective access to the failure store of a data stream via the `::failures` selector in search and related APIs. A role with the `read_failure_store` index privilege grants access to the failure store, without granting access to the data in a data stream. Conversely, the existing `read` privilege only grants access to data and _not_ the failure store. This requires changes to both the role building logic, and authorization. Going forward, each named index privilege is assigned a selector it grants access to, e.g., `read` grants access to the implicit `::data` selector, `read_failure_store` grants access to `::failures`. When building a role from role descriptors, we partition its underlying index groups by selector access such that any given group grants access to a single selector (with the exception of `all`, which grants access to all selectors). This PR implements this partitioning logic and sets up roles to implement selector-aware authorization in a follow up. Note that parts of the code make assumption around the existence of only two distinct selectors (`::data` and `::failures`) to simplify the implementation; however, it's possible to generalize these sections to support more selectors in the future, if necessary. Closes: ES-10872
4 tasks
elasticsearchmachine
pushed a commit
that referenced
this pull request
Mar 20, 2025
This PR implements authorization logic for failure store access. It builds on #122715. Access to the failure store is granted by two privileges: `read_failure_store` and `manage_failure_store`. Either of these privileges lets a user access a failure store via the `::failures` selector, as well as access its backing failure indices. `read_failure_store` grants read access (for example to search documents in a failure store), `manage_failure_store` grants access to write operations, such as rollover. Users with only `read` or `manage` on a data stream do not get failure store access. Vice versa, users with `read_failure_store` and `manage_failure_store` do not get access to regular data in a data stream. The PR implements this by making authorization logic selector-aware. It involves two main changes: 1. Index permission groups now compare the selector under which an index resource is accessed to the selector associated with the group. 2. The `AuthorizedIndices` interface likewise uses selectors to decide which indices to treat as authorized. This part of the change requires a sizable refactor and changes to the interface. The high-level behavior for selector-aware search is as follows: For a user with `read_failure_store` over data stream `logs`: - `POST /logs::failures/_search` returns the documents in the failure store. - `POST /logs/_search` returns a 403. - `POST /logs/_search?ignore_unavailable=true` and `POST /*/_search` return an empty result. Similarly, for a user with `read` over data stream `logs`: - `POST /logs::failures/_search` returns a 403. - `POST /logs/_search` returns documents in the data stream. - `POST /logs::failures/_search?ignore_unavailable=true` and `POST /*::failures/_search` return an empty result. A user with both `read` and `read_failure_store` over data stream `logs` gets access to both `POST /logs::failures/_search` and `POST /logs/_search`. The index privilege `all` automatically grants access to both data and the failures store, as well as all hypothetical future selectors. Resolves: ES-10873
💚 All backports created successfully
Questions ?Please refer to the Backport tool documentation |
elasticsearchmachine
pushed a commit
that referenced
this pull request
Mar 20, 2025
afoucret
pushed a commit
to afoucret/elasticsearch
that referenced
this pull request
Mar 21, 2025
This PR implements authorization logic for failure store access. It builds on elastic#122715. Access to the failure store is granted by two privileges: `read_failure_store` and `manage_failure_store`. Either of these privileges lets a user access a failure store via the `::failures` selector, as well as access its backing failure indices. `read_failure_store` grants read access (for example to search documents in a failure store), `manage_failure_store` grants access to write operations, such as rollover. Users with only `read` or `manage` on a data stream do not get failure store access. Vice versa, users with `read_failure_store` and `manage_failure_store` do not get access to regular data in a data stream. The PR implements this by making authorization logic selector-aware. It involves two main changes: 1. Index permission groups now compare the selector under which an index resource is accessed to the selector associated with the group. 2. The `AuthorizedIndices` interface likewise uses selectors to decide which indices to treat as authorized. This part of the change requires a sizable refactor and changes to the interface. The high-level behavior for selector-aware search is as follows: For a user with `read_failure_store` over data stream `logs`: - `POST /logs::failures/_search` returns the documents in the failure store. - `POST /logs/_search` returns a 403. - `POST /logs/_search?ignore_unavailable=true` and `POST /*/_search` return an empty result. Similarly, for a user with `read` over data stream `logs`: - `POST /logs::failures/_search` returns a 403. - `POST /logs/_search` returns documents in the data stream. - `POST /logs::failures/_search?ignore_unavailable=true` and `POST /*::failures/_search` return an empty result. A user with both `read` and `read_failure_store` over data stream `logs` gets access to both `POST /logs::failures/_search` and `POST /logs/_search`. The index privilege `all` automatically grants access to both data and the failures store, as well as all hypothetical future selectors. Resolves: ES-10873
smalyshev
pushed a commit
to smalyshev/elasticsearch
that referenced
this pull request
Mar 21, 2025
This PR implements authorization logic for failure store access. It builds on elastic#122715. Access to the failure store is granted by two privileges: `read_failure_store` and `manage_failure_store`. Either of these privileges lets a user access a failure store via the `::failures` selector, as well as access its backing failure indices. `read_failure_store` grants read access (for example to search documents in a failure store), `manage_failure_store` grants access to write operations, such as rollover. Users with only `read` or `manage` on a data stream do not get failure store access. Vice versa, users with `read_failure_store` and `manage_failure_store` do not get access to regular data in a data stream. The PR implements this by making authorization logic selector-aware. It involves two main changes: 1. Index permission groups now compare the selector under which an index resource is accessed to the selector associated with the group. 2. The `AuthorizedIndices` interface likewise uses selectors to decide which indices to treat as authorized. This part of the change requires a sizable refactor and changes to the interface. The high-level behavior for selector-aware search is as follows: For a user with `read_failure_store` over data stream `logs`: - `POST /logs::failures/_search` returns the documents in the failure store. - `POST /logs/_search` returns a 403. - `POST /logs/_search?ignore_unavailable=true` and `POST /*/_search` return an empty result. Similarly, for a user with `read` over data stream `logs`: - `POST /logs::failures/_search` returns a 403. - `POST /logs/_search` returns documents in the data stream. - `POST /logs::failures/_search?ignore_unavailable=true` and `POST /*::failures/_search` return an empty result. A user with both `read` and `read_failure_store` over data stream `logs` gets access to both `POST /logs::failures/_search` and `POST /logs/_search`. The index privilege `all` automatically grants access to both data and the failures store, as well as all hypothetical future selectors. Resolves: ES-10873
omricohenn
pushed a commit
to omricohenn/elasticsearch
that referenced
this pull request
Mar 28, 2025
This PR implements authorization logic for failure store access. It builds on elastic#122715. Access to the failure store is granted by two privileges: `read_failure_store` and `manage_failure_store`. Either of these privileges lets a user access a failure store via the `::failures` selector, as well as access its backing failure indices. `read_failure_store` grants read access (for example to search documents in a failure store), `manage_failure_store` grants access to write operations, such as rollover. Users with only `read` or `manage` on a data stream do not get failure store access. Vice versa, users with `read_failure_store` and `manage_failure_store` do not get access to regular data in a data stream. The PR implements this by making authorization logic selector-aware. It involves two main changes: 1. Index permission groups now compare the selector under which an index resource is accessed to the selector associated with the group. 2. The `AuthorizedIndices` interface likewise uses selectors to decide which indices to treat as authorized. This part of the change requires a sizable refactor and changes to the interface. The high-level behavior for selector-aware search is as follows: For a user with `read_failure_store` over data stream `logs`: - `POST /logs::failures/_search` returns the documents in the failure store. - `POST /logs/_search` returns a 403. - `POST /logs/_search?ignore_unavailable=true` and `POST /*/_search` return an empty result. Similarly, for a user with `read` over data stream `logs`: - `POST /logs::failures/_search` returns a 403. - `POST /logs/_search` returns documents in the data stream. - `POST /logs::failures/_search?ignore_unavailable=true` and `POST /*::failures/_search` return an empty result. A user with both `read` and `read_failure_store` over data stream `logs` gets access to both `POST /logs::failures/_search` and `POST /logs/_search`. The index privilege `all` automatically grants access to both data and the failures store, as well as all hypothetical future selectors. Resolves: ES-10873
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.
This PR adds the
read_failure_storeindex privilege and extends the role building logic to support selector-aware authorization. Note that this PR only concerns building roles; the actual authorization logic implementation will follow in a separate PR. The overall approach is based on the proof-of-concept PR (#122007).The purpose of the
read_failure_storeindex privilege is to support granting selective access to the failure store of a data stream via the::failuresselector in search and related APIs. A role with theread_failure_storeindex privilege grants access to the failure store, without granting access to the data in a data stream. Conversely, the existingreadprivilege only grants access to data and not the failure store.This requires changes to both the role building logic, and authorization. Going forward, each named index privilege is assigned a selector it grants access to, e.g.,
readgrants access to the implicit::dataselector,read_failure_storegrants access to::failures. When building a role from role descriptors, we partition its underlying index groups by selector access such that any given group grants access to a single selector (with the exception ofall, which grants access to all selectors).This PR implements this partitioning logic and sets up roles to implement selector-aware authorization in a follow up. Note that parts of the code make assumption around the existence of only two distinct selectors (
::dataand::failures) to simplify the implementation; however, it's possible to generalize these sections to support more selectors in the future, if necessary.Closes: ES-10872