-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SecuritySolution] Breaking out timeline & note privileges #201780
[SecuritySolution] Breaking out timeline & note privileges #201780
Conversation
…monschke/kibana into security/timeline-privileges
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the changes!
⏳ Build in-progress
History
cc @janmonschke |
Starting backport for target branches: 8.x |
💔 All backports failed
Manual backportTo create the backport manually run:
Questions ?Please refer to the Backport tool documentation |
export enum ProductFeatureTimelineFeatureKey { | ||
/** | ||
* Enables Timeline | ||
*/ | ||
timeline = 'timeline', | ||
} | ||
|
||
export enum ProductFeatureNotesFeatureKey { | ||
/** | ||
* Enables Notes | ||
*/ | ||
notes = 'notes', | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are these feature keys for? Can't find where they are used
@@ -32,10 +32,12 @@ | |||
{ | |||
"feature": { | |||
"ml": ["read"], | |||
"siem": ["read", "read_alerts"], | |||
"siemV2": ["read", "read_alerts"], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is read_alerts
? just curiosity
💚 All backports created successfully
Note: Successful backport PRs will be merged automatically after passing CI. Questions ?Please refer to the Backport tool documentation |
…01780) ## Summary Epic: elastic/security-team#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: ```mermaid 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 ``` ### 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 | | --- | --- | | <img width="616" alt="Screenshot 2024-12-18 at 17 22 49" src="https://github.com/user-attachments/assets/a767fbb5-49c8-422a-817e-23e7fe1f0042" /> | <img width="724" alt="Screenshot 2024-12-18 at 17 23 29" src="https://github.com/user-attachments/assets/3490306a-d1c3-41aa-af5b-05a1dd804b47" /> | #### Roles Another visible change of this PR is the addition of `Timeline` and `Notes` in the edit-role screen: | Before | After | | ------- | ------ | | <img width="746" alt="Screenshot 2024-12-12 at 16 31 43" src="https://github.com/user-attachments/assets/20a80dd4-c214-48a5-8c6e-3dc19c0cbc43" /> | <img width="738" alt="Screenshot 2024-12-12 at 16 32 53" src="https://github.com/user-attachments/assets/afb1eab4-1729-4c4e-9f51-fddabc32b1dd" /> | 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: <img width="354" alt="Screenshot 2024-12-19 at 10 34 23" src="https://github.com/user-attachments/assets/1304005e-2753-4268-b6e7-bd7e22d8a1e3" /> ### 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. - [x] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md) - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios - [x] 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. --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: PhilippeOberti <philippe.oberti@elastic.co> Co-authored-by: Steph Milovic <stephanie.milovic@elastic.co> (cherry picked from commit 1b167d9) # Conflicts: # x-pack/solutions/security/plugins/security_solution/public/app/actions/add_to_timeline/discover/add_to_timeline.ts # x-pack/solutions/security/plugins/security_solution/public/management/links.ts # x-pack/solutions/security/plugins/security_solution/public/timelines/containers/index.test.tsx # x-pack/test/security_solution_api_integration/config/services/security_solution_ess_utils.ts # x-pack/test/security_solution_api_integration/config/services/security_solution_serverless_utils.ts # x-pack/test/security_solution_api_integration/config/services/types.ts
…01780) ## Summary Epic: elastic/security-team#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: ```mermaid 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 ``` ### 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 | | --- | --- | | <img width="616" alt="Screenshot 2024-12-18 at 17 22 49" src="https://github.com/user-attachments/assets/a767fbb5-49c8-422a-817e-23e7fe1f0042" /> | <img width="724" alt="Screenshot 2024-12-18 at 17 23 29" src="https://github.com/user-attachments/assets/3490306a-d1c3-41aa-af5b-05a1dd804b47" /> | #### Roles Another visible change of this PR is the addition of `Timeline` and `Notes` in the edit-role screen: | Before | After | | ------- | ------ | | <img width="746" alt="Screenshot 2024-12-12 at 16 31 43" src="https://github.com/user-attachments/assets/20a80dd4-c214-48a5-8c6e-3dc19c0cbc43" /> | <img width="738" alt="Screenshot 2024-12-12 at 16 32 53" src="https://github.com/user-attachments/assets/afb1eab4-1729-4c4e-9f51-fddabc32b1dd" /> | 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: <img width="354" alt="Screenshot 2024-12-19 at 10 34 23" src="https://github.com/user-attachments/assets/1304005e-2753-4268-b6e7-bd7e22d8a1e3" /> ### 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. - [x] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md) - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios - [x] 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. --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: PhilippeOberti <philippe.oberti@elastic.co> Co-authored-by: Steph Milovic <stephanie.milovic@elastic.co>
…07373) # Backport This will backport the following commits from `main` to `8.x`: - [[Security Solution] Fix old siem feature override (#207333)](#207333) <!--- Backport version: 9.4.3 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT [{"author":{"name":"Sergi Massaneda","email":"sergi.massaneda@elastic.co"},"sourceCommit":{"committedDate":"2025-01-21T14:50:53Z","message":"[Security Solution] Fix old siem feature override (#207333)\n\n## Summary\r\n\r\nAdds the feature override for the old `siem` feature as well, we changed\r\nthat to the new one here\r\n\r\n\r\nhttps://github.com//pull/201780/files#diff-5aba630e58630c087c90368aa97296afb736f62579a23285cef901dc1c3921edR27\r\n\r\nRelated failure: https://github.com/elastic/kibana/issues/207285\r\n\r\nThe problem happened because MKI tests are using the outdated roles\r\ndefinition with the old `feature_siem` which was lacking the feature\r\noverride in the serverless.security.yml\r\n\r\nCo-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>","sha":"9077414852f86a70aba5259e9f62d12a53a63090","branchLabelMapping":{"^v9.0.0$":"main","^v8.18.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","v9.0.0","Team:Threat Hunting","ci:build-serverless-image","backport:version","v8.18.0"],"title":"[Security Solution] Fix old siem feature override","number":207333,"url":"https://github.com/elastic/kibana/pull/207333","mergeCommit":{"message":"[Security Solution] Fix old siem feature override (#207333)\n\n## Summary\r\n\r\nAdds the feature override for the old `siem` feature as well, we changed\r\nthat to the new one here\r\n\r\n\r\nhttps://github.com//pull/201780/files#diff-5aba630e58630c087c90368aa97296afb736f62579a23285cef901dc1c3921edR27\r\n\r\nRelated failure: https://github.com/elastic/kibana/issues/207285\r\n\r\nThe problem happened because MKI tests are using the outdated roles\r\ndefinition with the old `feature_siem` which was lacking the feature\r\noverride in the serverless.security.yml\r\n\r\nCo-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>","sha":"9077414852f86a70aba5259e9f62d12a53a63090"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/207333","number":207333,"mergeCommit":{"message":"[Security Solution] Fix old siem feature override (#207333)\n\n## Summary\r\n\r\nAdds the feature override for the old `siem` feature as well, we changed\r\nthat to the new one here\r\n\r\n\r\nhttps://github.com//pull/201780/files#diff-5aba630e58630c087c90368aa97296afb736f62579a23285cef901dc1c3921edR27\r\n\r\nRelated failure: https://github.com/elastic/kibana/issues/207285\r\n\r\nThe problem happened because MKI tests are using the outdated roles\r\ndefinition with the old `feature_siem` which was lacking the feature\r\noverride in the serverless.security.yml\r\n\r\nCo-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>","sha":"9077414852f86a70aba5259e9f62d12a53a63090"}},{"branch":"8.x","label":"v8.18.0","branchLabelMappingKey":"^v8.18.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}] BACKPORT--> Co-authored-by: Sergi Massaneda <sergi.massaneda@elastic.co>
…1780) (#207367) # Backport This will backport the following commits from `main` to `8.x`: - [[SecuritySolution] Breaking out timeline & note privileges (#201780)](#201780) <!--- Backport version: 9.6.4 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport) <!--BACKPORT [{"author":{"name":"Jan Monschke","email":"jan.monschke@elastic.co"},"sourceCommit":{"committedDate":"2025-01-20T13:09:16Z","message":"[SecuritySolution] Breaking out timeline & note privileges (#201780)\n\n## Summary\n\nEpic: https://github.com/elastic/security-team/issues/7998\n\nIn this PR we're breaking out the `timeline` and `notes` features into\ntheir own feature privilege definition. Previously, access to both\nfeatures was granted implicitly through the `siem` feature. However, we\nfound that this level of access control is not sufficient for all\nclients who wanted a more fine-grained way to grant access to parts of\nsecurity solution.\n\nIn order to break out `timeline` and `notes` from `siem`, we had to\ndeprecate it feature privilege definition for. That is why you'll find\nplenty of changes of `siem` to `siemV2` in this PR. We're making use of\nthe feature privilege's `replacedBy` functionality, allowing for a\nseamless migration of deprecated roles.\n\nThis means that roles that previously granted `siem.all` are now granted\n`siemV2.all`, `timeline.all` and `notes.all` (same for `*.read`).\nExisting users are not impacted and should all still have the correct\naccess. We added tests to make sure this is working as expected.\n\nAlongside the `ui` privileges, this PR also adds dedicated API tags.\nThose tags haven been added to the new and previous version of the\nprivilege definitions to allow for a clean migration:\n\n```mermaid\nflowchart LR\n subgraph v1\n A(siem) --> Y(all)\n A --> X(read)\n Y -->|api| W(timeline_write / timeline_read / notes_read / notes_write)\n X -->|api| V(timeline_read /notes_read)\n end\n\n subgraph v2\n A-->|replacedBy| C[siemV2]\n A-->|replacedBy| E[timeline]\n A-->|replacedBy| G[notes]\n \n\n E --> L(all)\n E --> M(read)\n L -->|api| N(timeline_write / timeline_read)\n M -->|api| P(timeline_read)\n\n G --> Q(all)\n G --> I(read)\n\n Q -->|api| R(notes_write / notes_read)\n I -->|api| S(notes_read)\n end\n```\n\n### Visual changes\n\n#### Hidden/disabled elements\n\nMost of the changes are happening \"under\" the hood and are only\nexpressed in case a user has a role with `timeline.none` or\n`notes.none`. This would hide and/or disable elements that would usually\nallow them to interact with either timeline or the notes feature (within\ntimeline or the event flyout currently).\n\nAs an example, this is how the hover actions look for a user with and\nwithout timeline access:\n\n| With timeline access | Without timeline access |\n| --- | --- |\n| <img width=\"616\" alt=\"Screenshot 2024-12-18 at 17 22 49\"\nsrc=\"https://github.com/user-attachments/assets/a767fbb5-49c8-422a-817e-23e7fe1f0042\"\n/> | <img width=\"724\" alt=\"Screenshot 2024-12-18 at 17 23 29\"\nsrc=\"https://github.com/user-attachments/assets/3490306a-d1c3-41aa-af5b-05a1dd804b47\"\n/> |\n\n#### Roles\n\nAnother visible change of this PR is the addition of `Timeline` and\n`Notes` in the edit-role screen:\n\n| Before | After |\n| ------- | ------ |\n| <img width=\"746\" alt=\"Screenshot 2024-12-12 at 16 31 43\"\nsrc=\"https://github.com/user-attachments/assets/20a80dd4-c214-48a5-8c6e-3dc19c0cbc43\"\n/> | <img width=\"738\" alt=\"Screenshot 2024-12-12 at 16 32 53\"\nsrc=\"https://github.com/user-attachments/assets/afb1eab4-1729-4c4e-9f51-fddabc32b1dd\"\n/> |\n\nWe made sure that for migrated roles that hard `security.all` selected,\nthis screen correctly shows `security.all`, `timeline.all` and\n`notes.all` after the privilege migration.\n\n#### Timeline toast\n\nThere are tons of places in security solution where `Investigate / Add\nto timeline` are shown. We did our best to disable all of these actions\nbut there is no guarantee that this PR catches all the places where we\nlink to timeline (actions). One layer of extra protection is that the\nAPI endpoints don't give access to timelines to users without the\ncorrect privileges. Another one is a Redux middleware that makes sure\ntimelines cannot be shown in missed cases. The following toast will be\nshown instead of the timeline:\n\n<img width=\"354\" alt=\"Screenshot 2024-12-19 at 10 34 23\"\nsrc=\"https://github.com/user-attachments/assets/1304005e-2753-4268-b6e7-bd7e22d8a1e3\"\n/>\n\n### Changes to predefined security roles\n\nAll predefined security roles have been updated to grant the new\nprivileges (in ESS and serverless). In accordance with the migration,\nall roles with `siem.all` have been assigned `siemV2.all`,\n`timeline.all` and `notes.all` (and `*.read` respectively).\n\n### Checklist\n\nCheck the PR satisfies following conditions. \n\nReviewers should verify this PR satisfies this list as well.\n\n- [x] Any text added follows [EUI's writing\nguidelines](https://elastic.github.io/eui/#/guidelines/writing), uses\nsentence case text and includes [i18n\nsupport](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)\n- [x] [Unit or functional\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\nwere updated or added to match the most common scenarios\n- [x] This was checked for breaking HTTP API changes, and any breaking\nchanges have been approved by the breaking-change committee. The\n`release_note:breaking` label should be applied in these situations.\n\n---------\n\nCo-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>\nCo-authored-by: PhilippeOberti <philippe.oberti@elastic.co>\nCo-authored-by: Steph Milovic <stephanie.milovic@elastic.co>","sha":"1b167d9dc23a9e0e8e47992a37563ca89ccf3c7d","branchLabelMapping":{"^v9.0.0$":"main","^v8.18.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Team:Fleet","v9.0.0","release_note:feature","Team:Threat Hunting:Investigations","backport:prev-minor","ci:cloud-deploy","ci:project-persist-deployment","v8.18.0"],"title":"[SecuritySolution] Breaking out timeline & note privileges","number":201780,"url":"https://github.com/elastic/kibana/pull/201780","mergeCommit":{"message":"[SecuritySolution] Breaking out timeline & note privileges (#201780)\n\n## Summary\n\nEpic: https://github.com/elastic/security-team/issues/7998\n\nIn this PR we're breaking out the `timeline` and `notes` features into\ntheir own feature privilege definition. Previously, access to both\nfeatures was granted implicitly through the `siem` feature. However, we\nfound that this level of access control is not sufficient for all\nclients who wanted a more fine-grained way to grant access to parts of\nsecurity solution.\n\nIn order to break out `timeline` and `notes` from `siem`, we had to\ndeprecate it feature privilege definition for. That is why you'll find\nplenty of changes of `siem` to `siemV2` in this PR. We're making use of\nthe feature privilege's `replacedBy` functionality, allowing for a\nseamless migration of deprecated roles.\n\nThis means that roles that previously granted `siem.all` are now granted\n`siemV2.all`, `timeline.all` and `notes.all` (same for `*.read`).\nExisting users are not impacted and should all still have the correct\naccess. We added tests to make sure this is working as expected.\n\nAlongside the `ui` privileges, this PR also adds dedicated API tags.\nThose tags haven been added to the new and previous version of the\nprivilege definitions to allow for a clean migration:\n\n```mermaid\nflowchart LR\n subgraph v1\n A(siem) --> Y(all)\n A --> X(read)\n Y -->|api| W(timeline_write / timeline_read / notes_read / notes_write)\n X -->|api| V(timeline_read /notes_read)\n end\n\n subgraph v2\n A-->|replacedBy| C[siemV2]\n A-->|replacedBy| E[timeline]\n A-->|replacedBy| G[notes]\n \n\n E --> L(all)\n E --> M(read)\n L -->|api| N(timeline_write / timeline_read)\n M -->|api| P(timeline_read)\n\n G --> Q(all)\n G --> I(read)\n\n Q -->|api| R(notes_write / notes_read)\n I -->|api| S(notes_read)\n end\n```\n\n### Visual changes\n\n#### Hidden/disabled elements\n\nMost of the changes are happening \"under\" the hood and are only\nexpressed in case a user has a role with `timeline.none` or\n`notes.none`. This would hide and/or disable elements that would usually\nallow them to interact with either timeline or the notes feature (within\ntimeline or the event flyout currently).\n\nAs an example, this is how the hover actions look for a user with and\nwithout timeline access:\n\n| With timeline access | Without timeline access |\n| --- | --- |\n| <img width=\"616\" alt=\"Screenshot 2024-12-18 at 17 22 49\"\nsrc=\"https://github.com/user-attachments/assets/a767fbb5-49c8-422a-817e-23e7fe1f0042\"\n/> | <img width=\"724\" alt=\"Screenshot 2024-12-18 at 17 23 29\"\nsrc=\"https://github.com/user-attachments/assets/3490306a-d1c3-41aa-af5b-05a1dd804b47\"\n/> |\n\n#### Roles\n\nAnother visible change of this PR is the addition of `Timeline` and\n`Notes` in the edit-role screen:\n\n| Before | After |\n| ------- | ------ |\n| <img width=\"746\" alt=\"Screenshot 2024-12-12 at 16 31 43\"\nsrc=\"https://github.com/user-attachments/assets/20a80dd4-c214-48a5-8c6e-3dc19c0cbc43\"\n/> | <img width=\"738\" alt=\"Screenshot 2024-12-12 at 16 32 53\"\nsrc=\"https://github.com/user-attachments/assets/afb1eab4-1729-4c4e-9f51-fddabc32b1dd\"\n/> |\n\nWe made sure that for migrated roles that hard `security.all` selected,\nthis screen correctly shows `security.all`, `timeline.all` and\n`notes.all` after the privilege migration.\n\n#### Timeline toast\n\nThere are tons of places in security solution where `Investigate / Add\nto timeline` are shown. We did our best to disable all of these actions\nbut there is no guarantee that this PR catches all the places where we\nlink to timeline (actions). One layer of extra protection is that the\nAPI endpoints don't give access to timelines to users without the\ncorrect privileges. Another one is a Redux middleware that makes sure\ntimelines cannot be shown in missed cases. The following toast will be\nshown instead of the timeline:\n\n<img width=\"354\" alt=\"Screenshot 2024-12-19 at 10 34 23\"\nsrc=\"https://github.com/user-attachments/assets/1304005e-2753-4268-b6e7-bd7e22d8a1e3\"\n/>\n\n### Changes to predefined security roles\n\nAll predefined security roles have been updated to grant the new\nprivileges (in ESS and serverless). In accordance with the migration,\nall roles with `siem.all` have been assigned `siemV2.all`,\n`timeline.all` and `notes.all` (and `*.read` respectively).\n\n### Checklist\n\nCheck the PR satisfies following conditions. \n\nReviewers should verify this PR satisfies this list as well.\n\n- [x] Any text added follows [EUI's writing\nguidelines](https://elastic.github.io/eui/#/guidelines/writing), uses\nsentence case text and includes [i18n\nsupport](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)\n- [x] [Unit or functional\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\nwere updated or added to match the most common scenarios\n- [x] This was checked for breaking HTTP API changes, and any breaking\nchanges have been approved by the breaking-change committee. The\n`release_note:breaking` label should be applied in these situations.\n\n---------\n\nCo-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>\nCo-authored-by: PhilippeOberti <philippe.oberti@elastic.co>\nCo-authored-by: Steph Milovic <stephanie.milovic@elastic.co>","sha":"1b167d9dc23a9e0e8e47992a37563ca89ccf3c7d"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/201780","number":201780,"mergeCommit":{"message":"[SecuritySolution] Breaking out timeline & note privileges (#201780)\n\n## Summary\n\nEpic: https://github.com/elastic/security-team/issues/7998\n\nIn this PR we're breaking out the `timeline` and `notes` features into\ntheir own feature privilege definition. Previously, access to both\nfeatures was granted implicitly through the `siem` feature. However, we\nfound that this level of access control is not sufficient for all\nclients who wanted a more fine-grained way to grant access to parts of\nsecurity solution.\n\nIn order to break out `timeline` and `notes` from `siem`, we had to\ndeprecate it feature privilege definition for. That is why you'll find\nplenty of changes of `siem` to `siemV2` in this PR. We're making use of\nthe feature privilege's `replacedBy` functionality, allowing for a\nseamless migration of deprecated roles.\n\nThis means that roles that previously granted `siem.all` are now granted\n`siemV2.all`, `timeline.all` and `notes.all` (same for `*.read`).\nExisting users are not impacted and should all still have the correct\naccess. We added tests to make sure this is working as expected.\n\nAlongside the `ui` privileges, this PR also adds dedicated API tags.\nThose tags haven been added to the new and previous version of the\nprivilege definitions to allow for a clean migration:\n\n```mermaid\nflowchart LR\n subgraph v1\n A(siem) --> Y(all)\n A --> X(read)\n Y -->|api| W(timeline_write / timeline_read / notes_read / notes_write)\n X -->|api| V(timeline_read /notes_read)\n end\n\n subgraph v2\n A-->|replacedBy| C[siemV2]\n A-->|replacedBy| E[timeline]\n A-->|replacedBy| G[notes]\n \n\n E --> L(all)\n E --> M(read)\n L -->|api| N(timeline_write / timeline_read)\n M -->|api| P(timeline_read)\n\n G --> Q(all)\n G --> I(read)\n\n Q -->|api| R(notes_write / notes_read)\n I -->|api| S(notes_read)\n end\n```\n\n### Visual changes\n\n#### Hidden/disabled elements\n\nMost of the changes are happening \"under\" the hood and are only\nexpressed in case a user has a role with `timeline.none` or\n`notes.none`. This would hide and/or disable elements that would usually\nallow them to interact with either timeline or the notes feature (within\ntimeline or the event flyout currently).\n\nAs an example, this is how the hover actions look for a user with and\nwithout timeline access:\n\n| With timeline access | Without timeline access |\n| --- | --- |\n| <img width=\"616\" alt=\"Screenshot 2024-12-18 at 17 22 49\"\nsrc=\"https://github.com/user-attachments/assets/a767fbb5-49c8-422a-817e-23e7fe1f0042\"\n/> | <img width=\"724\" alt=\"Screenshot 2024-12-18 at 17 23 29\"\nsrc=\"https://github.com/user-attachments/assets/3490306a-d1c3-41aa-af5b-05a1dd804b47\"\n/> |\n\n#### Roles\n\nAnother visible change of this PR is the addition of `Timeline` and\n`Notes` in the edit-role screen:\n\n| Before | After |\n| ------- | ------ |\n| <img width=\"746\" alt=\"Screenshot 2024-12-12 at 16 31 43\"\nsrc=\"https://github.com/user-attachments/assets/20a80dd4-c214-48a5-8c6e-3dc19c0cbc43\"\n/> | <img width=\"738\" alt=\"Screenshot 2024-12-12 at 16 32 53\"\nsrc=\"https://github.com/user-attachments/assets/afb1eab4-1729-4c4e-9f51-fddabc32b1dd\"\n/> |\n\nWe made sure that for migrated roles that hard `security.all` selected,\nthis screen correctly shows `security.all`, `timeline.all` and\n`notes.all` after the privilege migration.\n\n#### Timeline toast\n\nThere are tons of places in security solution where `Investigate / Add\nto timeline` are shown. We did our best to disable all of these actions\nbut there is no guarantee that this PR catches all the places where we\nlink to timeline (actions). One layer of extra protection is that the\nAPI endpoints don't give access to timelines to users without the\ncorrect privileges. Another one is a Redux middleware that makes sure\ntimelines cannot be shown in missed cases. The following toast will be\nshown instead of the timeline:\n\n<img width=\"354\" alt=\"Screenshot 2024-12-19 at 10 34 23\"\nsrc=\"https://github.com/user-attachments/assets/1304005e-2753-4268-b6e7-bd7e22d8a1e3\"\n/>\n\n### Changes to predefined security roles\n\nAll predefined security roles have been updated to grant the new\nprivileges (in ESS and serverless). In accordance with the migration,\nall roles with `siem.all` have been assigned `siemV2.all`,\n`timeline.all` and `notes.all` (and `*.read` respectively).\n\n### Checklist\n\nCheck the PR satisfies following conditions. \n\nReviewers should verify this PR satisfies this list as well.\n\n- [x] Any text added follows [EUI's writing\nguidelines](https://elastic.github.io/eui/#/guidelines/writing), uses\nsentence case text and includes [i18n\nsupport](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)\n- [x] [Unit or functional\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\nwere updated or added to match the most common scenarios\n- [x] This was checked for breaking HTTP API changes, and any breaking\nchanges have been approved by the breaking-change committee. The\n`release_note:breaking` label should be applied in these situations.\n\n---------\n\nCo-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>\nCo-authored-by: PhilippeOberti <philippe.oberti@elastic.co>\nCo-authored-by: Steph Milovic <stephanie.milovic@elastic.co>","sha":"1b167d9dc23a9e0e8e47992a37563ca89ccf3c7d"}},{"branch":"8.x","label":"v8.18.0","branchLabelMappingKey":"^v8.18.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}] BACKPORT-->
## Summary This PR fixes the Privileges Required error when accessing the Asset Inventory page introduced by #201780, due to changes on the `siem` capability being migrated to `siemV2`. <img width="943" alt="image" src="https://github.com/user-attachments/assets/91fd6041-73b0-42e7-94b7-f4acadc25329" /> In order to fix it, the capability was changed to `siemV2.
…01780) ## Summary Epic: elastic/security-team#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: ```mermaid 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 ``` ### 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 | | --- | --- | | <img width="616" alt="Screenshot 2024-12-18 at 17 22 49" src="https://github.com/user-attachments/assets/a767fbb5-49c8-422a-817e-23e7fe1f0042" /> | <img width="724" alt="Screenshot 2024-12-18 at 17 23 29" src="https://github.com/user-attachments/assets/3490306a-d1c3-41aa-af5b-05a1dd804b47" /> | #### Roles Another visible change of this PR is the addition of `Timeline` and `Notes` in the edit-role screen: | Before | After | | ------- | ------ | | <img width="746" alt="Screenshot 2024-12-12 at 16 31 43" src="https://github.com/user-attachments/assets/20a80dd4-c214-48a5-8c6e-3dc19c0cbc43" /> | <img width="738" alt="Screenshot 2024-12-12 at 16 32 53" src="https://github.com/user-attachments/assets/afb1eab4-1729-4c4e-9f51-fddabc32b1dd" /> | 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: <img width="354" alt="Screenshot 2024-12-19 at 10 34 23" src="https://github.com/user-attachments/assets/1304005e-2753-4268-b6e7-bd7e22d8a1e3" /> ### 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. - [x] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md) - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios - [x] 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. --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: PhilippeOberti <philippe.oberti@elastic.co> Co-authored-by: Steph Milovic <stephanie.milovic@elastic.co>
## Summary This PR fixes the Privileges Required error when accessing the Asset Inventory page introduced by elastic#201780, due to changes on the `siem` capability being migrated to `siemV2`. <img width="943" alt="image" src="https://github.com/user-attachments/assets/91fd6041-73b0-42e7-94b7-f4acadc25329" /> In order to fix it, the capability was changed to `siemV2.
## Summary This PR fixes the Privileges Required error when accessing the Asset Inventory page introduced by elastic#201780, due to changes on the `siem` capability being migrated to `siemV2`. <img width="943" alt="image" src="https://github.com/user-attachments/assets/91fd6041-73b0-42e7-94b7-f4acadc25329" /> In order to fix it, the capability was changed to `siemV2.
## Summary We forgot to update this privilege in #201780 . The endpoint only uses the scoped SO client, so this missing privilege declaration does not lead to privilege escalation on the endpoint. There are automated tests that check for the correct privilege access for this and other endpoints.
…verless (#208911) ## Summary Remove the implicit grant of the `savedQueryManagement` feature with the Security Solution basic feature (ID: `siemV2`) in Serverless. This is a follow-up of #202863 ### Feature `siemV2` This change only affects new roles created with the `siemV2` feature, introduced recently [here](#201780). This change will align the Roles UI in Serverless and ESS, both requiring the `savedQueryManagement` feature to be explicitly granted to be able to manage saved queries. ### Feature `siem` Roles using the deprecated `siem` feature will still implicitly receive the `savedQueryManagement` feature (via an implicit grant of `discover`, `dashboard`, `visualize`, and `maps`) + migration to their `*v2` features which include `savedQueryManagement`. So there's no behavior change for existing roles using the old `siem` feature (no breaking change). ## Screenshots The siem/siemV2 feature toggle: <img width="774" alt="siem feature" src="https://github.com/user-attachments/assets/2759988a-3cf8-4e1f-9431-16c09cf9d95c" /> The savedQueryManagement feature toggle: <img width="774" alt="Saved query feature" src="https://github.com/user-attachments/assets/d0145244-f4b8-4577-b91f-93f4dd1f758b" />
…verless (elastic#208911) ## Summary Remove the implicit grant of the `savedQueryManagement` feature with the Security Solution basic feature (ID: `siemV2`) in Serverless. This is a follow-up of elastic#202863 ### Feature `siemV2` This change only affects new roles created with the `siemV2` feature, introduced recently [here](elastic#201780). This change will align the Roles UI in Serverless and ESS, both requiring the `savedQueryManagement` feature to be explicitly granted to be able to manage saved queries. ### Feature `siem` Roles using the deprecated `siem` feature will still implicitly receive the `savedQueryManagement` feature (via an implicit grant of `discover`, `dashboard`, `visualize`, and `maps`) + migration to their `*v2` features which include `savedQueryManagement`. So there's no behavior change for existing roles using the old `siem` feature (no breaking change). ## Screenshots The siem/siemV2 feature toggle: <img width="774" alt="siem feature" src="https://github.com/user-attachments/assets/2759988a-3cf8-4e1f-9431-16c09cf9d95c" /> The savedQueryManagement feature toggle: <img width="774" alt="Saved query feature" src="https://github.com/user-attachments/assets/d0145244-f4b8-4577-b91f-93f4dd1f758b" /> (cherry picked from commit 3d5972a)
Summary
Epic: https://github.com/elastic/security-team/issues/7998
In this PR we're breaking out the
timeline
andnotes
features into their own feature privilege definition. Previously, access to both features was granted implicitly through thesiem
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
andnotes
fromsiem
, we had to deprecate it feature privilege definition for. That is why you'll find plenty of changes ofsiem
tosiemV2
in this PR. We're making use of the feature privilege'sreplacedBy
functionality, allowing for a seamless migration of deprecated roles.This means that roles that previously granted
siem.all
are now grantedsiemV2.all
,timeline.all
andnotes.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: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
ornotes.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:
Roles
Another visible change of this PR is the addition of
Timeline
andNotes
in the edit-role screen:We made sure that for migrated roles that hard
security.all
selected, this screen correctly showssecurity.all
,timeline.all
andnotes.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 assignedsiemV2.all
,timeline.all
andnotes.all
(and*.read
respectively).Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
release_note:breaking
label should be applied in these situations.