[SecuritySolution] Breaking out timeline & note privileges

[janmonschke]

Summary

Epic: https://github.com/elastic/security-team/issues/7998

In this PR we're breaking out the timeline and notes features into their own feature privilege definition. Previously, access to both features was granted implicitly through the siem feature. However, we found that this level of access control is not sufficient for all clients who wanted a more fine-grained way to grant access to parts of security solution.

In order to break out timeline and notes from siem, we had to deprecate it feature privilege definition for. That is why you'll find plenty of changes of siem to siemV2 in this PR. We're making use of the feature privilege's replacedBy functionality, allowing for a seamless migration of deprecated roles.

This means that roles that previously granted siem.all are now granted siemV2.all, timeline.all and notes.all (same for *.read). Existing users are not impacted and should all still have the correct access. We added tests to make sure this is working as expected.

Alongside the ui privileges, this PR also adds dedicated API tags. Those tags haven been added to the new and previous version of the privilege definitions to allow for a clean migration:

flowchart LR
    subgraph v1
    A(siem) --> Y(all)
    A --> X(read)
    Y -->|api| W(timeline_write / timeline_read / notes_read / notes_write)
    X -->|api| V(timeline_read /notes_read)
    end

    subgraph v2
    A-->|replacedBy| C[siemV2]
    A-->|replacedBy| E[timeline]
    A-->|replacedBy| G[notes]
    

    E --> L(all)
    E --> M(read)
    L -->|api| N(timeline_write / timeline_read)
    M -->|api| P(timeline_read)

    G --> Q(all)
    G --> I(read)

    Q -->|api| R(notes_write / notes_read)
    I -->|api| S(notes_read)
    end

Loading

Visual changes

Hidden/disabled elements

Most of the changes are happening "under" the hood and are only expressed in case a user has a role with timeline.none or notes.none. This would hide and/or disable elements that would usually allow them to interact with either timeline or the notes feature (within timeline or the event flyout currently).

As an example, this is how the hover actions look for a user with and without timeline access:

With timeline access	Without timeline access

Roles

Another visible change of this PR is the addition of Timeline and Notes in the edit-role screen:

Before	After

We made sure that for migrated roles that hard security.all selected, this screen correctly shows security.all, timeline.all and notes.all after the privilege migration.

Timeline toast

There are tons of places in security solution where Investigate / Add to timeline are shown. We did our best to disable all of these actions but there is no guarantee that this PR catches all the places where we link to timeline (actions). One layer of extra protection is that the API endpoints don't give access to timelines to users without the correct privileges. Another one is a Redux middleware that makes sure timelines cannot be shown in missed cases. The following toast will be shown instead of the timeline:

Changes to predefined security roles

All predefined security roles have been updated to grant the new privileges (in ESS and serverless). In accordance with the migration, all roles with siem.all have been assigned siemV2.all, timeline.all and notes.all (and *.read respectively).

Checklist

Check the PR satisfies following conditions.

Reviewers should verify this PR satisfies this list as well.

• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• 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.

[cnasikas]

Thanks for the changes!

[elasticmachine]

⏳ Build in-progress

• Buildkite Build
• Commit: 22cd732
• Cloud Deployment

History

• 💚 Build #268359 succeeded f7270c3
• 💛 Build #267751 was flaky 7284797
• 💛 Build #267685 was flaky 68804d1
• 💚 Build #267096 succeeded a8a4073
• 💛 Build #266807 was flaky b3c6a8a
• 💚 Build #266475 succeeded 7437310

cc @janmonschke

[kibanamachine]

Starting backport for target branches: 8.x

https://github.com/elastic/kibana/actions/runs/12868746627

[kibanamachine]

💔 All backports failed

Status	Branch	Result
❌	8.x	Backport failed because of merge conflicts You might need to backport the following PRs to 8.x: - [Security Solution] Fix timeline dynamic batching (#204034)

Manual backport

To create the backport manually run:

node scripts/backport --pr 201780

Questions ?

Please refer to the Backport tool documentation

[semd]

Why are these feature keys for? Can't find where they are used

[semd]

What is read_alerts? just curiosity

[janmonschke]

💚 All backports created successfully

Status	Branch	Result
✅	8.x

Note: Successful backport PRs will be merged automatically after passing CI.

Questions ?

Please refer to the Backport tool documentation