Skip to content

[Detections & Response] RBAC - Add Detection Alerts kibana feature#244637

Draft
denar50 wants to merge 65 commits intoelastic:mainfrom
denar50:rbac-alerts-feature
Draft

[Detections & Response] RBAC - Add Detection Alerts kibana feature#244637
denar50 wants to merge 65 commits intoelastic:mainfrom
denar50:rbac-alerts-feature

Conversation

@denar50
Copy link
Contributor

@denar50 denar50 commented Nov 28, 2025

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):

Screenshot 2026-02-12 at 4 51 28 PM

The change is part of the broader Security Solution RBAC Epic and follows the same pattern as:

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).

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).

Elastic Assistant (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).

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

@elasticmachine
Copy link
Contributor

elasticmachine commented Nov 28, 2025

🤖 Jobs for this PR can be triggered through checkboxes. 🚧

ℹ️ To trigger the CI, please tick the checkbox below 👇

  • Click to trigger kibana-pull-request for this PR!
  • Click to trigger kibana-deploy-project-from-pr for this PR!
  • Click to trigger kibana-deploy-cloud-from-pr for this PR!

@denar50 denar50 force-pushed the rbac-alerts-feature branch from 6435eec to 6142b80 Compare December 1, 2025 12:50
@denar50 denar50 force-pushed the rbac-alerts-feature branch 2 times, most recently from d64c8f8 to 5898df9 Compare December 5, 2025 15:52
@rylnd rylnd force-pushed the rbac-alerts-feature branch from 96422b8 to e217ca3 Compare December 10, 2025 22:14
@denar50 denar50 force-pushed the rbac-alerts-feature branch 5 times, most recently from 3be4a8c to d9c710a Compare December 18, 2025 13:50
@denar50 denar50 force-pushed the rbac-alerts-feature branch 3 times, most recently from 7cde7ab to 18f65ab Compare December 19, 2025 15:05
@denar50 denar50 force-pushed the rbac-alerts-feature branch 4 times, most recently from 8c6db01 to 7d5a05d Compare January 19, 2026 11:36
@denar50 denar50 force-pushed the rbac-alerts-feature branch 2 times, most recently from 9023947 to 973d61d Compare January 22, 2026 14:44
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.
@rylnd rylnd force-pushed the rbac-alerts-feature branch from 731036c to 8de6415 Compare February 11, 2026 23:57
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).
@rylnd rylnd changed the title Rbac alerts feature [Detections & Response] RBAC - Add Detection Alerts kibana feature Feb 12, 2026
@rylnd rylnd self-assigned this Feb 12, 2026
@rylnd rylnd added release_note:feature Makes this part of the condensed release notes Feature:Detection Alerts/Rules RBAC Security Solution RBAC for rules and alerts Team:Detection Engine Security Solution Detection Engine Area v9.4.0 backport:skip This PR does not require backporting labels Feb 12, 2026
@pborgonovi pborgonovi added the ci:cloud-deploy Create or update a Cloud deployment label Feb 13, 2026
@pborgonovi
Copy link
Contributor

/ci

@rylnd
Copy link
Contributor

rylnd commented Feb 13, 2026

/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
@rylnd
Copy link
Contributor

rylnd commented Feb 17, 2026

/ci

@rylnd
Copy link
Contributor

rylnd commented Feb 18, 2026

/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.
@rylnd
Copy link
Contributor

rylnd commented Feb 18, 2026

/ci

alerting: {
alert: { all: alertingFeatures },
},
// TODO: figure out if this should be here
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@denar50 what's the story with this comment?

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
@rylnd
Copy link
Contributor

rylnd commented Feb 19, 2026

/ci

@elasticmachine
Copy link
Contributor

elasticmachine commented Feb 19, 2026

💔 Build Failed

Failed CI Steps

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id before after diff
securitySolution 8769 8771 +2

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id before after diff
securitySolution 11.1MB 11.1MB +1.9KB

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id before after diff
securitySolution 172.8KB 173.3KB +546.0B
securitySolutionEss 35.5KB 35.6KB +102.0B
securitySolutionServerless 47.2KB 47.3KB +98.0B
total +746.0B

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

backport:skip This PR does not require backporting ci:cloud-deploy Create or update a Cloud deployment Feature:Detection Alerts/Rules RBAC Security Solution RBAC for rules and alerts release_note:feature Makes this part of the condensed release notes Team:Detection Engine Security Solution Detection Engine Area v9.4.0

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants

Comments