[Detections & Response] RBAC - Add Detection Alerts kibana feature by denar50 · Pull Request #244637 · elastic/kibana

denar50 · 2025-11-28T12:13:53Z

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:

Rules RBAC — rules-specific read/all privileges
Exceptions RBAC — exceptions subfeatures under Rules

Summary of what moves:

Before	After
Alerts read/edit implied by Rules or legacy Security features	Alerts read/edit come from the Alerts feature (`securitySolutionAlertsV1`)
Update operations (status, assignees, tags) allowed with Rules read in some cases	Update requires Alerts `edit` (or legacy deprecated privilege for backward compatibility)

New privilege model:

Alerts feature – Read: read_alerts (UI), alerts-read (API). View alerts, open flyouts, see tables.
Alerts feature – All: 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)

API: Alert update routes (open/close, set tags, set assignees) now require ALERTS_API_ALL or ALERTS_API_UPDATE_DEPRECATED_PRIVILEGE. Read-only alert operations require ALERTS_API_READ.
UI: Alerts UI uses the Alerts feature’s read_alerts / edit_alerts; the capability switcher grants the deprecated update capability to legacy Security and Rules features so existing roles keep update behavior.
New configurations to consider: You can have Rules without Alerts (manage rules, no alert access) and Alerts without Rules (view/edit alerts, no rule management). Reviewers should sanity-check both.

Testing setup

Roles and users: As mentioned earlier, prebuilt roles can be used to examine how legacy roles will behave, and to verify backwards compatibility. However, the net new functionality/permissions can and should be tested with custom roles. Luckily, we've written some tools to assist with this.
- First, we have a script to generate users and roles from a yaml config file. Simply run the script to add/update the users and roles referenced in the yaml file.
- To get one started, I've prepared a yaml file with all nine permutations of the new Rules and Alerts RBAC permissions. To test a particular combination, simply log in as the user with the corresponding role. For example, to test Alerts edit without Rules access, log in as 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

Dashboards: Tiles and links that show or link to alerts respect Alerts read; any edit/action from a dashboard should respect Alerts edit.
Alerts table: Loads and shows data only when the user has Alerts read. Sorting, filtering, and column visibility should work for read users.
- Row actions: Status, assignees, tags, and other update actions are visible/enabled only when the user has Alerts edit (or legacy update).
- Bulk actions: Bulk status change, assignees, tags, etc. require Alerts edit; otherwise hidden or disabled.
Alerts flyout: Opens for read users; in-flyout update actions (status, assignees, tags) only for users with Alerts edit (or legacy update).

Timeline

Alerts shown in Timeline respect Alerts read; any in-Timeline action that updates an alert (e.g. status, assignee, tags) should require Alerts edit (or legacy update).
Note: Timeline still requires/uses ES permissions to fetch alerts data. In the same way as Dev Tools or Discover, It is not guarded by the Alerts feature permission.

Rule Details – Alerts tab

Alerts table on the Rule Details page follows the same rules: read-only for Alerts read; row/bulk update actions for Alerts edit (or legacy update).

Entity analytics (EA) – Risk contributions / flyout

Any UI that shows or updates alerts in the context of EA (e.g. risk contributions, flyout) should respect Alerts read for viewing and Alerts edit for updates.

Cases

Cases and case-attached alerts: Viewing alerts attached to a case requires Alerts read. Updating those alerts (status, assignees, tags) from the Case view should require Alerts edit (or legacy update).

Alerts Flyout

Any users lacking the Alerts privilege attempting to view an Alerts flyout should see instead a permissions callout:

Checklist for Reviewers

Confirmed Alerts read only can view alerts everywhere (Alerts page, Timeline, Rule Details, Cases, EA) but cannot perform update actions.
Confirmed Alerts read + edit can perform status/assignee/tag updates (row and bulk) in all areas above.
Confirmed Rules without Alerts cannot see or interact with alerts (or see appropriate empty/denied state).
Confirmed Alerts without Rules can use the Alerts page and alert actions without rule management access.
Confirmed legacy Security/Rules-only roles still have update capability (backward compatibility).

Related links

Checklist

Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
Documentation was added for features that require explanation or tutorials
Unit or functional tests were updated or added to match the most common scenarios
This was checked for breaking HTTP API changes, and any breaking changes have been approved by the breaking-change committee. The release_note:breaking label should be applied in these situations.
Flaky Test Runner was used on any tests changed

x-pack/solutions/security/packages/features/src/rules/v2_features/kibana_features.ts

rylnd · 2026-03-20T14:19:59Z

@elastic/response-ops FYI beyond checking the updated alerting.rule and alerting.alert privileges in the two new features, here, the one file to review is related to hiding the bulk actions UI for alerts-read users on our alerts tables.

maximpn

Rule Management Area changes LGTM 👍

I've smoke tested Rule Management and Alerts with the script generated users. The behavior has expect restrictions for users. It looks good to go.
The only thing to double check is Selected data view is unavailable error toast message shown to alerts-none|rules-read users.

Details on what have been tested

I tested Rule Management and Alerts parts of the functionality for the following users

alerts-none|rules-none user
This users can't see any SIEM UI as expected.
alerts-none|rules-read user
Got a toast error "Selected data view is unavailable". It appeared and disappeared quickly. I'm not sure if it's expected.
alerts-none|rules-all user
alerts-read|rules-none user
Users may see rule and exception ids written to the alert. This seems to be expected. Anyway the rules management page is unavailable without rules permissions.

alerts-read|rules-read user
alerts-read|rules-all user
alerts-all|rules-none user
alerts-all|rules-read user
alerts-all|rules-all user

maximpn · 2026-03-23T07:38:47Z

x-pack/platform/packages/shared/response-ops/alerts-table/hooks/use_toolbar_visibility.tsx

+      selectedRowsCount === 0 ||
+      selectedRowsCount === undefined ||
+      bulkActions.length === 0 ||
+      !bulkActions.some((panel) => panel.items?.length);


Was it a bug not taking panel.items into account?

Yes, that's why I fixed it 😉 . However, it wasn't a bug prior to this branch, since there wasn't previously a user who could see the alerts table but lacked alert actions. I detailed this in 84c6d94.

maximpn · 2026-03-23T07:42:10Z

x-pack/solutions/security/packages/features/src/alerts/index.ts

+import type { ProductFeatureParams } from '../types';
+import { alertsDefaultProductFeaturesConfig } from './product_feature_config';
+
+export const getAlertsFeature = (): ProductFeatureParams<ProductFeatureAlertsKey, string> => ({


I wonder whether we should comment on what a security feature does. We have increasing number of security features where the boundary might be not 100% clear. There is a Google Sheet(s) describing the behavior but it lives separately. A comment could make the description clearer to the code.

WDYT?

I agree. I see we already had a README; I've added dev-oriented documentation for the Security, Rules, and Alerts features in 3eed09b.

maximpn · 2026-03-23T09:41:47Z

...ions/security/plugins/security_solution/public/detections/components/alerts/content.test.tsx

+      getUserPrivilegesMockDefaultValue({
+        rulesPrivileges: {
+          rules: {
+            read: true,


Should we have tests without rules permissions?

I think that in general for these tests: a "happy path" "everything gets rendered" makes sense at the top level, along with breaking out privilege-specific tests at whichever level they're handled.

There are more specific tests in child components (e.g. Header) to this one, and this particular component doesn't have any privilege-specific logic at this level, but: I did add one high level "does not render 'Manage Rules'" test in 5517d72.

maximpn · 2026-03-23T11:31:34Z

x-pack/solutions/security/plugins/security_solution/public/rules/routes.test.tsx

+      expect(getExpectedLandingTab(defaultLandingTab)).toBeInTheDocument();
+    });
+
+    it('redirects to the default landing tab when user does not have access to endpoint exceptions', () => {


How should it work with #258556? Endpoint exceptions will be moved out. Do we expect to apply the same RBAC to the tab?

If the user does not have access to Endpoint Exceptions, then whether/where it's been moved isn't relevant to them.

If there is some other expected behavior here, please clarify.

This must've been the result of a bad merge resolution.

…criptions

Asserts that we do not render the "Manage Rules" link if you do not have access.

Conflicts: x-pack/solutions/security/plugins/security_solution/public/flyout_v2/document/document_flyout_wrapper.test.tsx x-pack/solutions/security/plugins/security_solution/public/flyout_v2/document/document_flyout_wrapper.tsx x-pack/solutions/security/plugins/security_solution/public/flyout_v2/document/tabs/overview_tab.tsx

cnasikas

ResponseOps file changes LGTM! I did not review the RBAC changes.

coderabbitai · 2026-03-24T15:32:15Z

Caution

Review failed

The head commit changed during the review from ca54f79 to b7ef23a.

✨ Finishing Touches

🧪 Generate unit tests (beta)

Create PR with unit tests

🛠️ Update Documentation: Commit on current branch
🛠️ Update Documentation: Create PR

Warning

Tools execution failed with the following error:

Failed to run tools: 13 INTERNAL: Received RST_STREAM with code 2 (Internal server error)

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

Conflicts: x-pack/solutions/security/plugins/security_solution/public/detection_engine/rule_details_ui/pages/rule_details/use_rule_details_tabs.tsx x-pack/solutions/security/plugins/security_solution/public/rules/routes.tsx

The component had a conflict, but an added test referred to the old parameter.

Conflicts: x-pack/solutions/security/plugins/security_solution/public/common/components/toolbar/bulk_actions/use_bulk_alert_closing_reason_items.tsx

dhurley14

Detection engine codeowners changes are straightforward and look good. I tested that the roles are migrated correctly too.

Read privileges migration

Dev tools shows no explicit alerts privileges for the security read role I created in main:

Here is the privilege summary for that same role when I switch to this branch, correctly showing the user role has Read for alerts, which is carried over from the Rules privilege, despite not having it explicitly in the role definition (see dev tools above) 👍 :

All privileges migration

Dev tools shows no explicit alerts privileges for the security all role I created in main:

Here is the privilege summary for that same role when I switched to this branch, correctly showing the user role has All for alerts, which is carried over from the Rules privilege despite not having it explicitly in the role definition (see dev tools above) 👍:

One component was renamed, and a new component was added to the hierarchy causing some additional mocks.

Conflicts: x-pack/solutions/security/plugins/security_solution/public/flyout_v2/shared/components/flyout_provider.test.tsx x-pack/solutions/security/plugins/security_solution/public/flyout_v2/shared/components/flyout_provider.tsx x-pack/solutions/security/plugins/security_solution/public/one_discover/alert_flyout_header_component/index.test.tsx x-pack/solutions/security/plugins/security_solution/public/one_discover/alert_flyout_overview_tab_component/index.test.tsx

elasticmachine · 2026-03-24T22:35:42Z

⏳ Build in-progress

History

💔 Build #415834 failed db369f3
💔 Build #415783 failed 094253d
💔 Build #415582 failed ca54f79
💛 Build #414999 was flaky 5517d72
💚 Build #414939 succeeded 3eed09b

cc @rylnd

denar50 force-pushed the rbac-alerts-feature branch from 6435eec to 6142b80 Compare December 1, 2025 12:50

rylnd mentioned this pull request Dec 3, 2025

[OBX-UX-MGMT] Store Alert Muted Status Directly in Alert Documents #240996

Merged

cnasikas mentioned this pull request Dec 4, 2025

[Response Ops][Alerts] Use the new kibana.alert.muted field in the alerts table #245228

Open

denar50 force-pushed the rbac-alerts-feature branch 2 times, most recently from d64c8f8 to 5898df9 Compare December 5, 2025 15:52

rylnd force-pushed the rbac-alerts-feature branch from 96422b8 to e217ca3 Compare December 10, 2025 22:14

denar50 force-pushed the rbac-alerts-feature branch 5 times, most recently from 3be4a8c to d9c710a Compare December 18, 2025 13:50

denar50 force-pushed the rbac-alerts-feature branch 3 times, most recently from 7cde7ab to 18f65ab Compare December 19, 2025 15:05

denar50 force-pushed the rbac-alerts-feature branch 4 times, most recently from 8c6db01 to 7d5a05d Compare January 19, 2026 11:36

denar50 force-pushed the rbac-alerts-feature branch 2 times, most recently from 9023947 to 973d61d Compare January 22, 2026 14:44

dplumlee mentioned this pull request Jan 22, 2026

[Security Solution] Rules managment RBAC subfeatures #250131

Merged

dplumlee reviewed Jan 22, 2026

View reviewed changes

x-pack/solutions/security/packages/features/src/rules/v2_features/kibana_features.ts Show resolved Hide resolved

denar50 force-pushed the rbac-alerts-feature branch 3 times, most recently from 816e816 to ca0a2c7 Compare January 23, 2026 13:34

denar50 force-pushed the rbac-alerts-feature branch from c7d2b4f to db639e7 Compare February 1, 2026 16:06

elastic deleted a comment from elasticmachine Feb 1, 2026

pzl requested review from paul-tavares and removed request for pzl March 20, 2026 12:35

chetnarajput-qasource mentioned this pull request Mar 23, 2026

[Security Solution][Bug]Single alert attachment Case activity allows Alert Details Flyout access to user with NONE Alert Privilege #255494

Closed

Merge branch 'main' into rbac-alerts-feature

bedeb2b

maximpn approved these changes Mar 23, 2026

View reviewed changes

rylnd added 3 commits March 23, 2026 10:53

Merge branch 'main' into rbac-alerts-feature

3d38c19

Fix bad imports causing linter failures

2ce14bd

This must've been the result of a bad merge resolution.

Fill out features README with Security, Rules, and Alerts feature des…

3eed09b

…criptions

paul-tavares approved these changes Mar 23, 2026

View reviewed changes

Add a high-level rendering test for the Alerts page

5517d72

Asserts that we do not render the "Manage Rules" link if you do not have access.

cnasikas approved these changes Mar 24, 2026

View reviewed changes

Merge branch 'main' into rbac-alerts-feature

b7ef23a

rylnd added 3 commits March 24, 2026 13:39

Merge branch 'main' into rbac-alerts-feature

094253d

Conflicts: x-pack/solutions/security/plugins/security_solution/public/detection_engine/rule_details_ui/pages/rule_details/use_rule_details_tabs.tsx x-pack/solutions/security/plugins/security_solution/public/rules/routes.tsx

Fix incomplete merge

30057ab

The component had a conflict, but an added test referred to the old parameter.

Merge branch 'main' into rbac-alerts-feature

db369f3

Conflicts: x-pack/solutions/security/plugins/security_solution/public/common/components/toolbar/bulk_actions/use_bulk_alert_closing_reason_items.tsx

dhurley14 approved these changes Mar 24, 2026

View reviewed changes

rylnd added 2 commits March 24, 2026 16:36

Fix added tests broken by upstream changes

44305f8

One component was renamed, and a new component was added to the hierarchy causing some additional mocks.

rylnd enabled auto-merge (squash) March 24, 2026 22:02

patrykkopycinski approved these changes Mar 25, 2026

View reviewed changes

rylnd merged commit be17148 into elastic:main Mar 25, 2026
19 checks passed

PhilippeOberti mentioned this pull request Mar 26, 2026

[Security Solution] fix missing privilege in new flyout not in the correct location #259678

Merged

3 tasks

rylnd mentioned this pull request Mar 31, 2026

[Detection Engine] Update Test Roles for Rules & Alerts RBAC #260543

Open

Conversation

denar50 commented Nov 28, 2025 • edited by rylnd Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What this Does

How to Review

Permissions change (high level)

Testing setup

Areas of Interest

Alerts Page

Timeline

Rule Details – Alerts tab

Entity analytics (EA) – Risk contributions / flyout

Cases

Alerts Flyout

Checklist for Reviewers

Related links

Checklist

Uh oh!

Uh oh!

rylnd commented Mar 20, 2026

Uh oh!

maximpn left a comment

Choose a reason for hiding this comment

Details on what have been tested

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cnasikas left a comment

Choose a reason for hiding this comment

Uh oh!

coderabbitai bot commented Mar 24, 2026

Review failed

Uh oh!

dhurley14 left a comment

Choose a reason for hiding this comment

Uh oh!

elasticmachine commented Mar 24, 2026

⏳ Build in-progress

History

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

20 participants

denar50 commented Nov 28, 2025 •

edited by rylnd

Loading