[Detections & Response] RBAC - Add Detection Alerts kibana feature#244637
Draft
denar50 wants to merge 65 commits intoelastic:mainfrom
Draft
[Detections & Response] RBAC - Add Detection Alerts kibana feature#244637denar50 wants to merge 65 commits intoelastic:mainfrom
denar50 wants to merge 65 commits intoelastic:mainfrom
Conversation
Contributor
|
🤖 Jobs for this PR can be triggered through checkboxes. 🚧
ℹ️ To trigger the CI, please tick the checkbox below 👇
|
6435eec to
6142b80
Compare
d64c8f8 to
5898df9
Compare
96422b8 to
e217ca3
Compare
3be4a8c to
d9c710a
Compare
7cde7ab to
18f65ab
Compare
8c6db01 to
7d5a05d
Compare
9023947 to
973d61d
Compare
dplumlee
reviewed
Jan 22, 2026
x-pack/solutions/security/packages/features/src/rules/v2_features/kibana_features.ts
Show resolved
Hide resolved
816e816 to
ca0a2c7
Compare
c7d2b4f to
db639e7
Compare
This was referenced Feb 6, 2026
When a user cannot manage alerts, there is no context menu for single alerts, and the context menu for bulk alerts is empty. Based on the above behavior, this commit simplifies the assertions for single alerts to simply verify that the context menu is absent/disabled, and for bulk actions it first expands the menu, then asserts that multiple "action" buttons are not present.
So that others might have a better idea of what they represent. We appear to _sometimes_ reuse the data-test-subj of an action for both the single alert context menu _and_ the bulk action menu, so there is both duplication and overlap in these selectors, but: it is at least true that the selectors I've grouped here appear on the bulk actions menu.
I noticed this command was taking a long time during test execution, and tracked it down to the fact that we were `waitForAlerts()`ing on every row that was selected in the table. As far as I am aware there is no reason to do this, and it is signficantly slower than just performing the assertion once as a "can I start selecting items" check.
731036c to
8de6415
Compare
The components being tested here ultimately rely on `useAlertsPrivileges`, which relies on `useUserPrivileges`. While this was previously mocked, here, the default values have changes, and so there were reference errors when trying to destructure the mocked values from the hook. After investigation, none of these manually mocked values affect the component/tests, and so I instead opted to use the default mock values for the hook (which had already been updated). The one exception to the above is the timeline privilege, for which I added an additional test (and mock value override).
Contributor
|
/ci |
Contributor
|
/ci |
Conflicts:
x-pack/solutions/security/plugins/security_solution/public/detection_engine/rule_details_ui/pages/rule_details/index.tsx
x-pack/solutions/security/plugins/security_solution/public/detection_engine/rule_management_ui/components/rules_table/use_columns.tsx
x-pack/solutions/security/plugins/security_solution/public/rules/routes.tsx
NB I also modified
x-pack/solutions/security/plugins/security_solution/public/detection_engine/rule_management_ui/components/rules_table/use_rule_details_url_with_landing_tab.ts
To default to the new RuleDetails.overview tab
Contributor
|
/ci |
Contributor
|
/ci |
I've posted a message to Product to confirm that this is the general behavior that we want (default to the overview page). Depending on the answer I'll update this call, and/or the newer RulesRedirect component that was added on this branch.
Since everyone can access the Overview tab (if they have rule access), it is a much more suitable "default" tab than either the Alerts tab or the logic previously contained in `useRuleDetailsUrlWithLandingTab`. As we no longer need to check permissions to determine where to land if unspecified (we only check permissions to validate and redirect if they _don't_ have access), much of this logic can be removed and/or simplified.
Contributor
|
/ci |
rylnd
reviewed
Feb 19, 2026
| alerting: { | ||
| alert: { all: alertingFeatures }, | ||
| }, | ||
| // TODO: figure out if this should be here |
I'm guessing that this was to temporarily satisfy the "no empty enums" linting rule, but: will confirm with the original author.
Conflicts: x-pack/solutions/security/plugins/security_solution/public/detections/components/attacks/table/attacks_group_take_action_items.test.tsx
Contributor
|
/ci |
Contributor
💔 Build Failed
Failed CI StepsMetrics [docs]Module Count
Async chunks
Page load bundle
History
cc @rylnd |
This reverts commit fbec322. This in fact _does_ prevent a type error in the ProductFeature types; will need to discuss with the team.
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
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.
What this Does
This PR introduces Alerts RBAC: a dedicated Kibana feature (
securitySolutionAlertsV1) for controlling who can view and edit detection alerts. Alerts permissions are moved out of the Rules feature and into this new Alerts feature, so that access to alerts (viewing, updating status, assigning, tagging) can be granted independently from rules (managing detection rules):The change is part of the broader Security Solution RBAC Epic and follows the same pattern as:
Summary of what moves:
securitySolutionAlertsV1)edit(or legacy deprecated privilege for backward compatibility)New privilege model:
read_alerts(UI),alerts-read(API). View alerts, open flyouts, see tables.edit_alerts(UI),alerts-all(API). All of the above plus: change status, set assignees, set tags, bulk actions.Backward compatibility is preserved for existing roles: users with only legacy Security (siem/siemV2/siemV3/siemV4) or Rules (securitySolutionRulesV1/V2) read access still get a deprecated “update alerts” capability so they can continue to perform alert updates until roles are migrated.
Note also that, similarly to the previous PRs for this epic, this does not update the prebuilt/test roles, which will come in a subsequent PR. This means that using an existing prebuilt role will implicitly exercise the role migration path, as do the existing tests.
How to Review
Permissions change (high level)
ALERTS_API_ALLorALERTS_API_UPDATE_DEPRECATED_PRIVILEGE. Read-only alert operations requireALERTS_API_READ.read_alerts/edit_alerts; the capability switcher grants the deprecated update capability to legacy Security and Rules features so existing roles keep update behavior.Testing setup
alerts-all|rules-none(password:changeme).Areas of Interest
Please verify behavior in these areas with Alerts read only vs Alerts read + edit (and, if possible, Rules without Alerts and Alerts without Rules).
Alerts Page
Timeline
Rule Details – Alerts tab
Elastic Assistant (EA) – Risk contributions / flyout
Cases
Checklist for Reviewers
Related links
Checklist
release_note:breakinglabel should be applied in these situations.