# Backport
This will backport the following commits from `main` to `8.x`:
- [[Security Solution][Siem migrations] Swap experimental flag for ESS
(#208541)](https://github.com/elastic/kibana/pull/208541)
<!--- 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-29T15:32:04Z","message":"[Security
Solution][Siem migrations] Swap experimental flag for ESS
(#208541)\n\n## Summary\r\n\r\nThis PR enables the SIEM migrations
experimental flag by default in\r\nESS/on-prem.\r\nWe keep the
experimental flag disabled in serverless
(using\r\n`config/serverless.security.yml`) since we don't want to
release it yet.\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"93f67462d25cf795dfad76ed4cf3d723dcc90e66","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","backport:version","v8.18.0"],"title":"[Security Solution][Siem
migrations] Swap experimental flag for
ESS","number":208541,"url":"https://github.com/elastic/kibana/pull/208541","mergeCommit":{"message":"[Security
Solution][Siem migrations] Swap experimental flag for ESS
(#208541)\n\n## Summary\r\n\r\nThis PR enables the SIEM migrations
experimental flag by default in\r\nESS/on-prem.\r\nWe keep the
experimental flag disabled in serverless
(using\r\n`config/serverless.security.yml`) since we don't want to
release it yet.\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"93f67462d25cf795dfad76ed4cf3d723dcc90e66"}},"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/208541","number":208541,"mergeCommit":{"message":"[Security
Solution][Siem migrations] Swap experimental flag for ESS
(#208541)\n\n## Summary\r\n\r\nThis PR enables the SIEM migrations
experimental flag by default in\r\nESS/on-prem.\r\nWe keep the
experimental flag disabled in serverless
(using\r\n`config/serverless.security.yml`) since we don't want to
release it yet.\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"93f67462d25cf795dfad76ed4cf3d723dcc90e66"}},{"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>
# Backport
This will backport the following commits from `main` to `8.x`:
- [[SecuritySolution] Breaking out timeline & note privileges
(#201780)](https://github.com/elastic/kibana/pull/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-->
# Backport
This will backport the following commits from `main` to `8.x`:
- [[Security Solution] Fix old siem feature override
(#207333)](https://github.com/elastic/kibana/pull/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/elastic/kibana/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/elastic/kibana/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/elastic/kibana/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>
# Backport
This will backport the following commits from `main` to `8.x`:
- [[Search] Inference Endpoints - Align rendering to plugin
(#203313)](https://github.com/elastic/kibana/pull/203313)
<!--- Backport version: 8.9.8 -->
### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)
<!--BACKPORT [{"author":{"name":"Rodney
Norris","email":"rodney.norris@elastic.co"},"sourceCommit":{"committedDate":"2024-12-09T18:36:16Z","message":"[Search]
Inference Endpoints - Align rendering to plugin (#203313)\n\n##
Summary\r\n\r\nThis PR removes rendering of the Inference Endpoints UI
from\r\n`enterprise_search` for stack and instead utilizes
the\r\n`search_inference_endpoints` plugin to render the UI for both
serverless\r\nand stack. This can be done by utilizing the
`search_navigation` plugin\r\nfor rendering the classic navigation for
stack.\r\n\r\nTo support this change the
`xpack.searchInferenceEndpoints.ui.enabled`\r\nwas updated to default to
`true` instead of only being set for\r\nserverless search. To account
for this change I have added\r\n`xpack.searchInferenceEndpoints.enabled:
false` to the serverless\r\nconfigs for both security and observability
to ensure the\r\n`search_inference_endpoints` plugin is disabled in both
of those\r\nprojects.\r\n\r\n### Checklist\r\n\r\n- [x] Any text added
follows [EUI's
writing\r\nguidelines](https://elastic.github.io/eui/#/guidelines/writing),
uses\r\nsentence case text and includes
[i18n\r\nsupport](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)\r\n-
[
]\r\n[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)\r\nwas
added for features that require explanation or tutorials\r\n- [ ] [Unit
or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common scenarios\r\n- [ ] This was
checked for breaking HTTP API changes, and any breaking\r\nchanges have
been approved by the breaking-change committee.
The\r\n`release_note:breaking` label should be applied in these
situations.\r\n- [ ] [Flaky
Test\r\nRunner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1)
was\r\nused on any tests changed\r\n\r\n---------\r\n\r\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>\r\nCo-authored-by:
Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"ebb4f503a5c9c0a3d883a706566920ae27fedfad","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:Search","backport:prev-minor","v8.18.0"],"number":203313,"url":"https://github.com/elastic/kibana/pull/203313","mergeCommit":{"message":"[Search]
Inference Endpoints - Align rendering to plugin (#203313)\n\n##
Summary\r\n\r\nThis PR removes rendering of the Inference Endpoints UI
from\r\n`enterprise_search` for stack and instead utilizes
the\r\n`search_inference_endpoints` plugin to render the UI for both
serverless\r\nand stack. This can be done by utilizing the
`search_navigation` plugin\r\nfor rendering the classic navigation for
stack.\r\n\r\nTo support this change the
`xpack.searchInferenceEndpoints.ui.enabled`\r\nwas updated to default to
`true` instead of only being set for\r\nserverless search. To account
for this change I have added\r\n`xpack.searchInferenceEndpoints.enabled:
false` to the serverless\r\nconfigs for both security and observability
to ensure the\r\n`search_inference_endpoints` plugin is disabled in both
of those\r\nprojects.\r\n\r\n### Checklist\r\n\r\n- [x] Any text added
follows [EUI's
writing\r\nguidelines](https://elastic.github.io/eui/#/guidelines/writing),
uses\r\nsentence case text and includes
[i18n\r\nsupport](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)\r\n-
[
]\r\n[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)\r\nwas
added for features that require explanation or tutorials\r\n- [ ] [Unit
or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common scenarios\r\n- [ ] This was
checked for breaking HTTP API changes, and any breaking\r\nchanges have
been approved by the breaking-change committee.
The\r\n`release_note:breaking` label should be applied in these
situations.\r\n- [ ] [Flaky
Test\r\nRunner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1)
was\r\nused on any tests changed\r\n\r\n---------\r\n\r\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>\r\nCo-authored-by:
Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"ebb4f503a5c9c0a3d883a706566920ae27fedfad"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","labelRegex":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/203313","number":203313,"mergeCommit":{"message":"[Search]
Inference Endpoints - Align rendering to plugin (#203313)\n\n##
Summary\r\n\r\nThis PR removes rendering of the Inference Endpoints UI
from\r\n`enterprise_search` for stack and instead utilizes
the\r\n`search_inference_endpoints` plugin to render the UI for both
serverless\r\nand stack. This can be done by utilizing the
`search_navigation` plugin\r\nfor rendering the classic navigation for
stack.\r\n\r\nTo support this change the
`xpack.searchInferenceEndpoints.ui.enabled`\r\nwas updated to default to
`true` instead of only being set for\r\nserverless search. To account
for this change I have added\r\n`xpack.searchInferenceEndpoints.enabled:
false` to the serverless\r\nconfigs for both security and observability
to ensure the\r\n`search_inference_endpoints` plugin is disabled in both
of those\r\nprojects.\r\n\r\n### Checklist\r\n\r\n- [x] Any text added
follows [EUI's
writing\r\nguidelines](https://elastic.github.io/eui/#/guidelines/writing),
uses\r\nsentence case text and includes
[i18n\r\nsupport](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)\r\n-
[
]\r\n[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)\r\nwas
added for features that require explanation or tutorials\r\n- [ ] [Unit
or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common scenarios\r\n- [ ] This was
checked for breaking HTTP API changes, and any breaking\r\nchanges have
been approved by the breaking-change committee.
The\r\n`release_note:breaking` label should be applied in these
situations.\r\n- [ ] [Flaky
Test\r\nRunner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1)
was\r\nused on any tests changed\r\n\r\n---------\r\n\r\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>\r\nCo-authored-by:
Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"ebb4f503a5c9c0a3d883a706566920ae27fedfad"}},{"branch":"8.x","label":"v8.18.0","labelRegex":"^v8.18.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
# Backport
This will backport the following commits from `main` to `8.x`:
- https://github.com/elastic/kibana/pull/193715
Note: Created the backport manually because of merge conflicts in
`config/serverless.security.yml`
Co-authored-by: Ignacio Rivas <rivasign@gmail.com>
# Backport
This will backport the following commits from `main` to `8.x`:
- [Update max supported package version
(#196551)](https://github.com/elastic/kibana/pull/196551)
<!--- Backport version: 9.4.3 -->
### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)
<!--BACKPORT [{"author":{"name":"Giorgos
Bamparopoulos","email":"georgios.bamparopoulos@elastic.co"},"sourceCommit":{"committedDate":"2024-10-16T16:40:00Z","message":"Update
max supported package version (#196551)\n\nUpdate the max supported
package version to 3.3.0\r\n\r\nRelated to
https://github.com/elastic/package-spec/pull/818","sha":"2f76b60b0e2646b71cbc95b0de559154dd947dca","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:enhancement","Team:Fleet","v9.0.0","backport:prev-minor"],"title":"Update
max supported package
version","number":196551,"url":"https://github.com/elastic/kibana/pull/196551","mergeCommit":{"message":"Update
max supported package version (#196551)\n\nUpdate the max supported
package version to 3.3.0\r\n\r\nRelated to
https://github.com/elastic/package-spec/pull/818","sha":"2f76b60b0e2646b71cbc95b0de559154dd947dca"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/196551","number":196551,"mergeCommit":{"message":"Update
max supported package version (#196551)\n\nUpdate the max supported
package version to 3.3.0\r\n\r\nRelated to
https://github.com/elastic/package-spec/pull/818","sha":"2f76b60b0e2646b71cbc95b0de559154dd947dca"}}]}]
BACKPORT-->
Co-authored-by: Giorgos Bamparopoulos <georgios.bamparopoulos@elastic.co>
# Backport
This will backport the following commits from `main` to `8.x`:
- [Flipped Security Entity Store flag to being a "disable" flag
(#195818)](https://github.com/elastic/kibana/pull/195818)
<!--- Backport version: 8.9.8 -->
### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)
<!--BACKPORT [{"author":{"name":"Jared
Burgett","email":"147995946+jaredburgettelastic@users.noreply.github.com"},"sourceCommit":{"committedDate":"2024-10-15T04:56:08Z","message":"Flipped
Security Entity Store flag to being a \"disable\" flag (#195818)\n\n##
Summary\r\n\r\nThe Security Solution Entity Store feature will now be
available by\r\ndefault. However, there will be a flag that can be
switched on, if\r\ndesired, to **disable** that feature
entirely.\r\n\r\nRegardless of whether this flag is enabled or not,
Security's Entity\r\nStore is still only fully enabled through an
enablement workflow. In\r\nother words, a Security Solution customer
must turn on the feature\r\nthrough an onboarding workflow in order to
enable its features.\r\n\r\nAdditionally, we are disabling this feature
in Serverless at first, to\r\nperform proper Serverless load/performance
testing. (We do not expect it\r\nto be significantly different than
ESS/ECH, but are doing so out of an\r\nabundance of
caution).\r\n\r\n---------\r\n\r\nCo-authored-by: Pablo Machado
<pablo.nevesmachado@elastic.co>","sha":"ea582dc65029f5537d6093c3fadb8b90b7768f91","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","v9.0.0","backport:prev-minor"],"number":195818,"url":"https://github.com/elastic/kibana/pull/195818","mergeCommit":{"message":"Flipped
Security Entity Store flag to being a \"disable\" flag (#195818)\n\n##
Summary\r\n\r\nThe Security Solution Entity Store feature will now be
available by\r\ndefault. However, there will be a flag that can be
switched on, if\r\ndesired, to **disable** that feature
entirely.\r\n\r\nRegardless of whether this flag is enabled or not,
Security's Entity\r\nStore is still only fully enabled through an
enablement workflow. In\r\nother words, a Security Solution customer
must turn on the feature\r\nthrough an onboarding workflow in order to
enable its features.\r\n\r\nAdditionally, we are disabling this feature
in Serverless at first, to\r\nperform proper Serverless load/performance
testing. (We do not expect it\r\nto be significantly different than
ESS/ECH, but are doing so out of an\r\nabundance of
caution).\r\n\r\n---------\r\n\r\nCo-authored-by: Pablo Machado
<pablo.nevesmachado@elastic.co>","sha":"ea582dc65029f5537d6093c3fadb8b90b7768f91"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","labelRegex":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/195818","number":195818,"mergeCommit":{"message":"Flipped
Security Entity Store flag to being a \"disable\" flag (#195818)\n\n##
Summary\r\n\r\nThe Security Solution Entity Store feature will now be
available by\r\ndefault. However, there will be a flag that can be
switched on, if\r\ndesired, to **disable** that feature
entirely.\r\n\r\nRegardless of whether this flag is enabled or not,
Security's Entity\r\nStore is still only fully enabled through an
enablement workflow. In\r\nother words, a Security Solution customer
must turn on the feature\r\nthrough an onboarding workflow in order to
enable its features.\r\n\r\nAdditionally, we are disabling this feature
in Serverless at first, to\r\nperform proper Serverless load/performance
testing. (We do not expect it\r\nto be significantly different than
ESS/ECH, but are doing so out of an\r\nabundance of
caution).\r\n\r\n---------\r\n\r\nCo-authored-by: Pablo Machado
<pablo.nevesmachado@elastic.co>","sha":"ea582dc65029f5537d6093c3fadb8b90b7768f91"}}]}]
BACKPORT-->
Co-authored-by: Jared Burgett <147995946+jaredburgettelastic@users.noreply.github.com>
# Backport
This will backport the following commits from `main` to `8.x`:
- [[ML] Update vCPUs ranges for start model deployment
(#195617)](https://github.com/elastic/kibana/pull/195617)
<!--- Backport version: 9.4.3 -->
### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)
<!--BACKPORT [{"author":{"name":"Dima
Arnautov","email":"dmitrii.arnautov@elastic.co"},"sourceCommit":{"committedDate":"2024-10-14T14:38:26Z","message":"[ML]
Update vCPUs ranges for start model deployment (#195617)\n\n##
Summary\r\n\r\n#### Different vCPUs ranges and enabling support for
static allocations\r\nbased on the serverless project type\r\n\r\n- Each
serverless config yml,
e.g.\r\n[search.es.yml](84b3b79a15/config/serverless.es.yml (L61))\r\nnow
contains parameters required for start model
deployment:\r\n\r\n```yml\r\nxpack.ml.nlp:\r\n enabled: true\r\n
modelDeployment:\r\n allowStaticAllocations: true\r\n vCPURange:\r\n
low:\r\n min: 0\r\n max: 2\r\n static: 2\r\n medium:\r\n min: 1\r\n max:
32\r\n static: 32\r\n high:\r\n min: 1\r\n max: 512\r\n static:
512\r\n```\r\n\r\nNote: _There will be no static allocations option for
serverless O11y\r\nand serverless Security._\r\n\r\n#### The minimum
values of vCPUs\r\n\r\n- 0 for the Low usage level on both serverless
and ESS.\r\n- 1 for the Medium and High usage levels on both serverless
and ESS.\r\n \r\n#### The default vCPUs usage levels\r\n- Low in
serverless.\r\n- Medium in ESS and on-prem\r\n\r\n### Checklist\r\n\r\n-
[x] [Unit or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common
scenarios","sha":"13897083dc8c465a16ddb3856d4e4904b9629610","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:enhancement",":ml","v9.0.0","Feature:3rd
Party
Models","Team:ML","ci:project-deploy-elasticsearch","ci:project-deploy-observability","v8.16.0","backport:version"],"title":"[ML]
Update vCPUs ranges for start model deployment
","number":195617,"url":"https://github.com/elastic/kibana/pull/195617","mergeCommit":{"message":"[ML]
Update vCPUs ranges for start model deployment (#195617)\n\n##
Summary\r\n\r\n#### Different vCPUs ranges and enabling support for
static allocations\r\nbased on the serverless project type\r\n\r\n- Each
serverless config yml,
e.g.\r\n[search.es.yml](84b3b79a15/config/serverless.es.yml (L61))\r\nnow
contains parameters required for start model
deployment:\r\n\r\n```yml\r\nxpack.ml.nlp:\r\n enabled: true\r\n
modelDeployment:\r\n allowStaticAllocations: true\r\n vCPURange:\r\n
low:\r\n min: 0\r\n max: 2\r\n static: 2\r\n medium:\r\n min: 1\r\n max:
32\r\n static: 32\r\n high:\r\n min: 1\r\n max: 512\r\n static:
512\r\n```\r\n\r\nNote: _There will be no static allocations option for
serverless O11y\r\nand serverless Security._\r\n\r\n#### The minimum
values of vCPUs\r\n\r\n- 0 for the Low usage level on both serverless
and ESS.\r\n- 1 for the Medium and High usage levels on both serverless
and ESS.\r\n \r\n#### The default vCPUs usage levels\r\n- Low in
serverless.\r\n- Medium in ESS and on-prem\r\n\r\n### Checklist\r\n\r\n-
[x] [Unit or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common
scenarios","sha":"13897083dc8c465a16ddb3856d4e4904b9629610"}},"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/195617","number":195617,"mergeCommit":{"message":"[ML]
Update vCPUs ranges for start model deployment (#195617)\n\n##
Summary\r\n\r\n#### Different vCPUs ranges and enabling support for
static allocations\r\nbased on the serverless project type\r\n\r\n- Each
serverless config yml,
e.g.\r\n[search.es.yml](84b3b79a15/config/serverless.es.yml (L61))\r\nnow
contains parameters required for start model
deployment:\r\n\r\n```yml\r\nxpack.ml.nlp:\r\n enabled: true\r\n
modelDeployment:\r\n allowStaticAllocations: true\r\n vCPURange:\r\n
low:\r\n min: 0\r\n max: 2\r\n static: 2\r\n medium:\r\n min: 1\r\n max:
32\r\n static: 32\r\n high:\r\n min: 1\r\n max: 512\r\n static:
512\r\n```\r\n\r\nNote: _There will be no static allocations option for
serverless O11y\r\nand serverless Security._\r\n\r\n#### The minimum
values of vCPUs\r\n\r\n- 0 for the Low usage level on both serverless
and ESS.\r\n- 1 for the Medium and High usage levels on both serverless
and ESS.\r\n \r\n#### The default vCPUs usage levels\r\n- Low in
serverless.\r\n- Medium in ESS and on-prem\r\n\r\n### Checklist\r\n\r\n-
[x] [Unit or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common
scenarios","sha":"13897083dc8c465a16ddb3856d4e4904b9629610"}},{"branch":"8.x","label":"v8.16.0","branchLabelMappingKey":"^v8.16.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->
Co-authored-by: Dima Arnautov <dmitrii.arnautov@elastic.co>
Kibana should already support packages with spec version 3.2, update the
max version in serverless.
Supersedes part of https://github.com/elastic/kibana/pull/184792.
Co-authored-by: Jen Huang <its.jenetic@gmail.com>
## Summary
Resolves https://github.com/elastic/kibana/issues/182827
As the title says :)
This also corrects `spec.max` to `3.1`, which it should have been all
along.
Integrations available for Observability projects after change:
[Click
here](b9592e60-0bda-4597-b7fc-0e7ee5a673da)
Integrations available for Security projects after change:
[Click
here](f74142ae-88d8-4445-96f7-413c12a1434b)
## Summary
This PR extends the features plugin to accept feature definition
overrides via Kibana configuration. The functionality is limited to the
Serverless offering only. Additionally, the PR updates Kibana serverless
configurations to include overrides based on the "simplified feature
toggles" proposals discussed with the solution teams.
The configuration might look like this:
```yaml
## Fine-tune the feature privileges.
xpack.features.overrides:
dashboard:
privileges:
### Dashboard's `All` feature privilege should implicitly
### grant `All` access to Maps and Visualize features.
all.composedOf:
- feature: "maps"
privileges: [ "all" ]
- feature: "visualize"
privileges: [ "all" ]
### All Dashboard sub-feature privileges should be hidden:
### reporting capabilities will be granted via dedicated
### Reporting feature and short URL sub-feature privilege
### should be granted for both `All` and `Read`.
subFeatures.privileges:
download_csv_report.disabled: true
url_create:
disabled: true
includeIn: "read"
### Maps feature is disabled since it's automatically granted by Dashboard feature.
maps.disabled: true
```
## How to test
Log in as the `admin` using SAML and navigate to the `Custom roles`
management section to edit role and see tuned role management UX:
<p align="center">
<img
src="ad6e4b07-53bd-4f5a-ae91-66d6534c711a"
/>
<img
src="8ab4d5a3-f719-42d5-a278-3aee87603c33"
/>
</p>
### Search project
```bash
yarn es serverless --projectType=es --ssl -E xpack.security.authc.native_roles.enabled=true
yarn start --serverless=es --ssl --xpack.security.roleManagementEnabled=true
```
Refer to the proposal document, `config/serverless.yml`, and
`config/serverless.es.yml` in this PR to see the specific changes made
for your project type:
Create a custom `custom-search` role and re-login as the user with this
role to test your project type (you need to manually type role name if
the role selector):
<p align="center">
<img
src="5088320b-3cc8-4de9-984c-d70fc6277659"
/>
</p>
### Observability project
```bash
yarn es serverless --projectType=oblt --ssl -E xpack.security.authc.native_roles.enabled=true
yarn start --serverless=oblt --ssl --xpack.security.roleManagementEnabled=true
```
Refer to the proposal document, `config/serverless.yml`, and
`config/serverless.oblt.yml` in this PR to see the specific changes made
for your project type:
Create a custom `custom-o11y` role and re-login as the user with this
role to test your project type (you need to manually type role name if
the role selector):
<p align="center">
<img
src="110572b1-f08a-4427-a687-5c2e0240a36b"
/>
</p>
### Security project
```bash
yarn es serverless --projectType=security --ssl -E xpack.security.authc.native_roles.enabled=true
yarn start --serverless=security --ssl --xpack.security.roleManagementEnabled=true
```
Refer to the proposal document, `config/serverless.yml`, and
`config/serverless.security.yml` in this PR to see the specific changes
made for your project type:
Create a custom `custom-security` role and re-login as the user with
this role to test your project type (you need to manually type role name
if the role selector):
<p align="center">
<img
src="2bec6ae2-8d19-4142-a479-9a81bc1fca14"
/>
</p>
__Fixes: https://github.com/elastic/kibana/issues/178963__
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR links the ESQL functionality in security solution to the
`discover:enableESQL` advanced setting. The advanced setting will only
be present in ESS, but not serverless
The way this should work to maintain parity with the rest of Kibana such
as discover and stack rules:
- By default ES|QL will be enabled across all Kibana
- When the ES|QL advanced setting is disabled:
- Timeline
- ES|QL tab should not be accessible on any newly created timelines
- Existing Timelines with an ES|QL query should still have the tab
accessible
- Rules
- New ES|QL rule should not be available to be created in the *Rule
Creation* workflow
- Existing ES|QL rules should still run and be able to be edited
**Timeline Demo Video:**
d5429be9-de37-43e2-882d-687b3371beb4
**Rules Demo Video:**
7df2fd11-bd2b-4e50-ad97-b6e1d0f7867a
---------
Co-authored-by: Vitalii Dmyterko <92328789+vitaliidm@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR enables the `xpack.ml.nlp.enabled` flag for the security project
in support of enabling ELSER for use with the Elastic Assistant.
Reference issue: https://github.com/elastic/security-team/issues/7995
Corresponding `project-controller` PR's here:
https://github.com/elastic/project-controller/pull/674https://github.com/elastic/project-controller/pull/751
---
As discussed in the above reference issue, this PR adds a task for
cleaning up NLP models at a regular interval if the `productTier` is not
`complete`. This `serverless-security:nlp-cleanup-task` will run every
`6hr`, attempting to cleanup any `pytorch` NLP models/aliases that were
either leftover from a `productTier` downgrade, or were manually created
using the ES trained model API's.
Note I: As recommended by the ResponseOps folks, the task is _always
registered_ regardless of the current `productTier`. When executed on
the `complete` `productTier`, an `UnrecoverableError` is thrown, which
will remove the task and prevent it from running again until Kibana is
restarted.
Note II: While the task interval is every `6hr`, when initially
registered we manually kick off an execution to ensure that any
resources are immediately cleaned up when a `productTier` change is
performed.
---
Both `complete` and `essentials` API integration tests have been added
to cover the above behavior. Please see:
*
[.../test_suites/genai/nlp_cleanup_task/basic_license_essentials_tier/task_execution.ts
](https://github.com/elastic/kibana/pull/175358/files#diff-b0cae16c5c6f77a90d53fcfab3bda6400ec13fe7f200d8c1f0dd3f1a0109af9f)
*
[.../test_suites/genai/nlp_cleanup_task/trial_license_complete_tier/task_execution.ts](https://github.com/elastic/kibana/pull/175358/files#diff-c69ec08309855f236ab90d4ba73f40636e52d706679bbab530956ff8d5560097)
---
Additionally, Event Based Telemetry (EBT) was added so cleanup, and any
associated failures can be tracked. Please see the
`NLP_CLEANUP_TASK_EVENT`, which has the below schema:
```
failedToDeleteCount: number; // Total number of NLP models failed to be cleaned up
message: string; // General message from task completion, either summary of task or error message
productTier: string; // Current productTier when task was run
totalInstalledCount: number; // Total number of NLP models deployed when task started
```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
issue: https://github.com/elastic/kibana/issues/179162
This PR brings the new navigation, with the solution-centric IA
(Information Architecture), to the ESS (stateful) Security Solution.
To do so, the implementation of the `navigationTree$`, which was
previously only implemented in serverless, has been integrated inside
the generic "security_solution" plugin, so now it is available for ESS
and serverless offerings.
In ESS users can still choose the navigation version, so we have to
temporarily keep supporting both, the classic and new navigation
implementations. After the rollout, the classic navigation components
will be removed and the unified links architecture should be reassessed.
The issue for the cleaning:
https://github.com/elastic/kibana/issues/179572
### Rollout
The new solutions navigation will not be available for customers on
8.14, it will only be enabled for internal Elastic users (via
Lauchdarkly), who will have the ability to opt out of it from their
profile menu. We'll collect feedback and telemetry and address any bugs
or improvements (together with the Kibana platform team). The plan is to
start making it available to customers in 8.15.
### Testing
Unless we add the _kibana.yml_ configurations to enable the new
navigation, the regular classic navigation will be displayed, it should
keep working the same way without any change. The new landing pages
(`Assets`, `Investigations`, `Machine Learning`,...), that exist only
when using the new navigation, should not be accessible using the
classic version.
To enable the new navigation add the following _kibana.yml_ configs:
```
xpack.cloud_integrations.experiments.enabled: true
xpack.cloud_integrations.experiments.flag_overrides:
"navigation.solutionNavEnabled": true
xpack.cloud.id: "ftr_fake_cloud_id:aGVsbG8uY29tOjQ0MyRFUzEyM2FiYyRrYm4xMjNhYmM="
xpack.cloud.base_url: "https://cloud.elastic.co"
xpack.cloud.deployment_url: "/deployments/deploymentId"
```
And enable the advanced setting
### Screenshots
The app switcher:
<img width="293" alt="app switcher"
src="0a638b8f-fdc0-4d1a-b8d3-607e487215f4">
---
New Assets landing page:
<img width="549" alt="assets landing"
src="17bc8a94-02b4-4996-b9f5-8731ba81ac43">
---
For `Stack Management` we set the nav panel flyout and the cards landing
page, this is temporary until a decision on how to show Stack Management
links is made:
<img width="954" alt="stack management"
src="27ce6534-0508-4804-b224-8dc409042825">
---
The switch to go back to the classic nav is in the profile menu at the
top-right corner:
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Søren Louv-Jansen <soren.louv@elastic.co>
Co-authored-by: Vitalii Dmyterko <92328789+vitaliidm@users.noreply.github.com>
Co-authored-by: jennypavlova <dzheni.pavlova@elastic.co>
Co-authored-by: Katerina <aikaterini.patticha@elastic.co>
Co-authored-by: Sébastien Loix <sebastien.loix@elastic.co>
Co-authored-by: Kurt <kc13greiner@users.noreply.github.com>
Co-authored-by: Justin Kambic <jk@elastic.co>
Co-authored-by: Julia Bardi <90178898+juliaElastic@users.noreply.github.com>
Co-authored-by: Paul Tavares <56442535+paul-tavares@users.noreply.github.com>
Co-authored-by: Nathan Reese <reese.nathan@elastic.co>
Co-authored-by: Dzmitry Lemechko <dzmitry.lemechko@elastic.co>
Co-authored-by: Marshall Main <55718608+marshallmain@users.noreply.github.com>
Co-authored-by: Milton Hultgren <milton.hultgren@elastic.co>
Disable the Obs AI Assistant plugin in Serverless Search & Serverless
Security. Some work was done to move `observabilityAIAssistant` from
`requiredPlugins` to `optionalPlugins` in upstream dependencies.
Closes https://github.com/elastic/kibana/issues/166999
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Introduced the console.ui.embeddedEnabled (boolean) value to allow
disabling the embedded console in serverless security and observability
projects.
This also replaces an index management specific config value to do that
same thing which is removed here as well. Adding this console
configuration will allow us to have one value to set instead of N which
was the pattern I had started to use, but then decided against.
### Checklist
- [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] If a plugin configuration key changed, check if it needs to be
allowlisted in the cloud and added to the [docker
list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)
- Rename `log_explorer` to `logs_explorer` and move it to an
`observability_solution` subfolder
- Rename `observability_log_explorer` to `observability_logs_explorer`
and move it to an `observability_solution` subfolder
- Use `renameFromRoot` to rename old configs
Related to https://github.com/elastic/kibana/issues/171991 and
https://github.com/elastic/kibana/pull/170759
This PR is mostly focused on renaming the plugins, follow ups will be
created to change mentions of `log explorer`, `logExplorer` etc.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Marco Antonio Ghiani <marcoantonio.ghiani01@gmail.com>
Adds a new `tags` property to our ML Modules which contains an array of
strings to used to filter the modules returned when calling
`/internal/ml/modules/get_module` or `/internal/ml/modules/recognize`
Adds a new kibana config setting `xpack.ml.compatibleModuleType` which
will enforce a module filter.
This setting supports the values `security`, `observability` or `search`
and will be used by the serverless projects to ensure only modules
relevant to the current project are discoverable.
When matching against the `xpack.ml.compatibleModuleType` setting,
modules with no tags will be returned along with modules which match the
`compatibleModuleType` value.
The endpoints `/internal/ml/modules/get_module` and
`/internal/ml/modules/recognize` can also take a `filter` query
parameter in the form of a comma separated list of values. If any of
these filter values match a module's tags, the module will be returned.
Modules with no tags will not be matched when using the `filter`
parameter.
This PR also updates the security plugin to apply a `security` filter
when retrieving modules and running recognize. This will improve
performance, especially for recognize which runs the queries from every
module on the supplied index pattern.
Examples
**Running the Security serverless project.**
Request:
`/internal/ml/modules/get_module`
Response:
All modules containing `tags: ["security"]`
Plus all modules with no `tags` or `tags: []`
Request:
`/internal/ml/modules/get_module?filter=observability`
Response:
An empty list
**Running stateful es**
Request:
`/internal/ml/modules/get_module`
Response:
All modules
Request:
`/internal/ml/modules/get_module?filter=security`
Response:
Only modules containing `tags: ["security"]`
Request:
`/internal/ml/modules/get_module?filter=security,observability`
Response:
Modules containing `tags: ["security"]` and `tags: ["observability"]`
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Closes https://github.com/elastic/ingest-dev/issues/2396
Added a new kibana task that publishes Agent metrics every minute to
data streams installed by fleet_server package.
Opened the pr for review, there are a few things to finalize, but the
core logic won't change much.
To test locally:
- Install fleet_server package 1.4.0 from
[this](https://github.com/elastic/integrations/pull/8145) pr to get the
mappings
- Start kibana locally, wait for a few minutes for the metrics task to
run (every minute)
- Go to discover, `metrics-*` index pattern, filter on
`data_stream.dataset: fleet_server.*`
- Expect data to be populated in `fleet_server.agent_status` and
`fleet_server.agent_versions` datasets.
<img width="1787" alt="image"
src="615af9df-fe4b-4c17-8c8c-88646c403a18">
### Checklist
- [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
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR implements a standard way to have different static settings for
the serverless and ess (stateful) environments. It centralizes flags,
which were set using different approaches previously, in a single
configuration.
This aims to make it easier for developers to enable/disable parts of
the application in serverless projects.
Default:
```
sideNavEnabled: true,
ILMEnabled: true,
ESQLEnabled: true,
```
Serverless:
```
xpack.securitySolution.offeringSettings: {
sideNavEnabled: false, # Internal security side navigation disabled, the serverless global chrome navigation is used instead
ILMEnabled: false, # Index Lifecycle Management (ILM) functionalities disabled, not supported by serverless Elasticsearch
ESQLEnabled: false, # ES|QL disabled, not supported by serverless Elasticsearch
}
```
### Consume the settings
#### Server
- Plugin parsed `ConfigType`:
`this.config.settings.ESQLEnabled`
#### UI
- Plugin attribute:
`this.configSettings.ESQLEnabled`.
- Components can access it from Kibana services:
`useKibana().services.configSettings.ESQLEnabled;`
---------
Co-authored-by: Vitalii Dmyterko <92328789+vitaliidm@users.noreply.github.com>
## Summary
This PR leverages the work done
[here](https://github.com/elastic/kibana/pull/165596) to introduce ES|QL
into timeline. The goal of this PR is to provide security users easy
access to ESQL from within the security solution. It will be released in
`technical preview` for the 8.11 release.
<img width="1725" alt="image"
src="0e275cf7-bbce-476b-b1dc-8936427ad14f">
### Checklist
Delete any items that are not applicable to this PR.
- [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
---------
Co-authored-by: Jatin Kathuria <jatin.kathuria@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Jatin Kathuria <jtn.kathuria@gmail.com>
Switches to using the serverless config file to enabled/disable ML
features rather than a function shared from the setup contract.
Storing these flags in a config file means they are already available
when setup runs and so can be used when registering integrations into
other plugins.
Removes the dependency on ML from `security_solution_serverless`,
`serverless_observability` and `serverless_search`
## Summary
First step for https://github.com/elastic/security-team/issues/6677
Aim of this PR is embed Discover in Security Solution. Discover must be
embedded as a complete app with certain set of capabilities working. The
set capabilities that need to working are listed here :
https://github.com/elastic/security-team/issues/6673
Release notes should be based on
https://github.com/elastic/security-team/issues/6673
### ⚠️ Note
- These changes are only available in serverless mode of security
solution behind a feature-flag called `discoverInTimeline`. Adds below
options to `serverless.security.yml`:
```yaml
# Serverless security specific options
xpack.securitySolution.enableExperimental:
- discoverInTimeline
```
You can use below command to run serverless instance of security
solution :
```bash
yarn serverless-security
```
This Implements following changes for each plugin.
### Discover
1. Exports Discover App as Lazy component.
2. Ability to override Discover Services.
3. Adds a parameter `mode` which switches off/on certain options based
on the `mode`. `Mode` has possible values of `embedded` and
`standalone`. For example, `embedded` switches off Discover breadcrumb
syncing, because consuming app may not need it.
### Unified Search
1. Ability to export a Search bar with custom depedency instances.
2. For example, today Unified Search uses a singleton global
`dataService` which store global KQL filters and queries. This
customization, let consumers of unified search to pass a new instance of
`dataService`.
4. Please see below diagram for more clarity.
### Navigation
1. Ability to export a custom stateful TopNav Menu which includes:
- DataView picker
- KQL Search Bar
- TimeRange Selector
2. Currently navigation consumes an instance of unified service which
uses a global singleton `data` service.
3. This PR creates a new instance of unified search which is then passed
to navigation to get a custom instance of `TopNav` Menu.
### Security Solution
1. Imports Discover Container Component
2. Uses customization point to pass a custom query bar.
3. Implements Custom KQL Query Bar with below customizations
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Davis McPhee <davis.mcphee@elastic.co>
## Summary
closes: https://github.com/elastic/kibana/issues/159685
- Renaming _x-pack/plugins_:
`serverless_security` -> `security_solution_serverless`
`ess_security` -> `security_solution_ess`
- All the related configurations and types have also been renamed.
- i18n translation prefixes updated
- relocation of internal `security_solution_serverless` directories to
be consistent with `security_solution_ess`
### Eslint
I also added the plugins in the `.eslintrc` configuration, defining the
same rules as the `security_solution` plugin.
All eslint errors have been addressed (mainly _type_ imports errors)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
# Summary
This PR adapts the endpoint RBAC to the new Serverless PLI features
architecture.
The changes are the following:
## App Features
### New appFeatures keys for endpoint
The `endpointExceptions` PLI has been added to the _Endpoint Essentials_
product tier and `endpointResponseActions` to the _Endpoint Complete_
686bc2eeaa/x-pack/plugins/serverless_security/common/pli/pli_config.ts (L20-L23)
### Endpoint appFeatures capabilities config
The features configuration for each appFeature (PLI) has been added.
They will be configured within the Security Kibana features only when
the appFeature is enabled by the selected Security product type. (Note
that all of them will be always added in regular ESS deployments, only
in Serverless we'll have different product types)
4d9f0c3a6f/x-pack/plugins/security_solution/server/lib/app_features/security_kibana_features.ts (L170-L198)
These are the capabilities that seemed relevant to me for each PLI, but
I don't have enough expertise in Endpoint operations to know for sure
what Kibana sub-features and capabilities need to be included in each
appFeature. The PLIs are in a private spreadsheet with the following
descriptions.
- endpointExceptions:
- endpointResponseActions:
I'll need Endpoint team members to confirm there's no missing or wrong
capability in each appFeature config.
### Host isolation capabilities
It is important to mention that in the configuration above, to have some
capabilities available we are adding some sub-features directly using
the `subFeatureIds` entry, but for host_isolation capabilities, we are
doing it in a slightly different way, using the `subFeaturesPrivileges`,
this way the privileges are added to existing subFeatures.
The reason is we need to have the _write_ (isolate operation) only in
payment product types, but the _read_ and _delete_ (release operation)
capabilities should be always available, to allow releasing previously
isolated hosts after a product downgrade.
To do this we always include the `host_isolation_all` and
`host_isolation_exceptions_all` subFeatures in the base configuration,
but they only contain _read_ and _delete_ capabilities by default, only
when the product tier allows the proper appFeatures the _write_
capability is added to the same subFeatures privileges.
## Endpoint Authz module
### Remove "superuser" specific check
This specific check:
```
// user is superuser, always return true
if (isSuperuser) {
return true;
}
```
Has been removed, this has no behavioral impact, superuser has all
capabilities enabled anyway.
### Remove usage of `endpointRbacEnabled` and `endpointRbacV1Enabled`
experimental flags
They are already enabled by default. superuser will still have the
authorization to access all the features. The only change is the
endpoint sub-features will always be visible in the Kibana Privilege
section of the Role management page, they were hidden when these
experimental flags were disabled.
### Remove double _write_ check for _read_ authorizations:
We were doing unnecessary checks for the _write_ capabilities in the
_read_ authorizations, like: ```
const canReadEndpointList = canWriteEndpointList ||
hasKibanaPrivilege(fleetAuthz, 'readEndpointList');
```. Sub-features already add _read_ and _write_ capabilities on the
`all` privilege, so these double checks were unnecessary.
### Extract `hasHostIsolationExceptionsItems` flag
This flag was used to grant _read_ and _delete_ authorization for Host
Isolation Exceptions (HIE) when there is data, basically turning them
free features when there is data to perform the actions. This is needed
to allow users to remove HIE after a license downgrade scenario, which
is good.
However, we needed to do this API call from outside the auth module, in
every place we needed to call `calculateEndpointAuthz`, and we were also
adding the responsibility to do some auth-specific logic with licenses
outside the auth module, which is not good.
In addition, it is not very consistent to make authorization depend on
the existence of data to perform an action. Authorization should be
based only on the role capabilities and tiers/licenses, if some parts of
the application want to show/hide stuff depending on the data, that's
not the auth module's responsibility.
I checked all the places where we use the HIE _read_ and _delete_
authorizations, and the only place where we really need them to be
denied (when there is no data) is in the _links_, we need to remove the
HIE link from the app in this situation.
So, this PR moves the data check to the links.ts module, making the
_read_ and _delete_ permissions always granted without a license (they
will still be useless without data), the same way the `canUnIsolateHost`
authorization works. And then doing the async data check to remove the
HIE link in the _management/links.ts_ module itself, only in the last
case where we really need to know it:
4d9f0c3a6f/x-pack/plugins/security_solution/public/management/links.ts (L257-L262)
This flag extraction is unrelated to the integration of the new
architecture, I included it only to extract complexity from the _authz_
module and simplify its usage, but this change can be rolled back if we
consider it.
# Testing
- To start the application in ESS (non-serverless) mode, run it normally
with `yarn start`. Everything should keep working as usual with all
features available and capabilities should only be restricted by the
user role.
- To start the application in Serverless mode run with `yarn
serverless-security`. It sets a random root path, so access the main URL
at "http://localhost:5601/" to be redirected.
By default the "Endpoint Complete" product line is selected in the
_serverless.security.yml_ config, so everything should be available as
in ESS with the default config.
686bc2eeaa/config/serverless.security.yml (L11-L15)
Once in Serverless mode, in order to see the difference between product
types, we can change the _Endpoint_ `product_tier` to `essentials`, as
per the pli_config, this change should remove all the capabilities
included by the `endpointResponseActions` appFeatures config.
To check how the application behaves without the `endpointExceptions`
PLI, we can remove the _Endpoint_ `product_line` entirely from the
product array, leaving the _Security_ `product_line` alone.
# Next steps
## Upselling page
The product upselling page has not been registered for endpoint pages in
this PR, so when any of these pages are unauthorized because of the
serverless product tier, and they are accessed directly by URL they
still show the `Privileges required` screen.
This is arguably not entirely correct. However, an upselling page can be
registered to display a "Buy a higher tier" message when the privilege
is denied because of the product type, if it is unauthorized because of
the user role the "Privileges required" page will still show.
I did not include the endpoint upselling page in this PR to keep it
simple, but the registry is already implemented in the main proposal, we
can define and register them in a follow-up PR.
## Superuser role in authz module
Almost all "superuser" role conditionals have been removed from the
Endpoint authz module, but there is only one check left here:
24330f2356/x-pack/plugins/security_solution/common/endpoint/service/authz/authz.ts (L85)
This `canAccessEndpointManagement` flag looks deprecated, and it seems
to be used incorrectly in the few places where it is checked. If we
could fix the places that it is used, checking the proper authz flag, we
could definitively remove the `userRoles` parameter from the
`calculateEndpointAuthz` function, this will have an impact in the
different places where this function is called since they will no longer
need any async logic.
---------
Co-authored-by: Pablo Neves Machado <pablo.nevesmachado@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
issue: https://github.com/elastic/kibana/issues/158810
follow-up of: https://github.com/elastic/kibana/pull/158179
Improves the Security AppFeatures architecture:
- SubFeatures now preserve always the same order in the Security Kibana
config, despite the order of processing of enabled appFeatures.
- Change the `productTypes` config format
- Update `getProductAppFeatures` to:
- process the new `productTypes` format.
- include _essentials_ tiers PLIs inside _complete_ tiers automatically.
- AppFeatures module now receives an array of PLIs instead of an object
- AppFeatures config now uses only SubFeature IDS instead of
`subActions` config objects directly
- Upselling components updated and `useProductTypeByPLI` implemented to
display the Product Type required
[Documentation](https://docs.google.com/document/d/1Ms8d8d_fbTTRHlBroEAKGNMNk3jFFgOAkVDRhqLxAPQ/edit?pli=1#)
issue: https://github.com/elastic/kibana/issues/158810
## Summary
This PR is a cleanup to make [this
POC](https://github.com/elastic/kibana/pull/155420) production ready
- Serverless PLI features splitting in Security Solution, to allow/deny
access to configured functionalities, using the current Kibana RBAC
service.
- Create the Upselling service to display Serveless-specific prompts in
the application when features are not available
- Create a `SecurityRoutePageWrapper` component that wraps Pages and
displays the upsell when necessary.
- We will refactor the code base to use `SecurityRoutePageWrapper`
everywhere on another PR.
- Create an Upsell page and section for entity analytics
bd8db822-2f4b-4545-9da7-bedc07d93f90
### test:
Serverless: `yarn serverless-security`.
* To change the product line you have to update
`xpack.serverless.security.productLineIds` on
`config/serverless.security.yml`.
ESS: `yarn start`
### Glossary
* PLI - Product Line Item (`Alert Triage`, `Osquery`, `Cases` , ... )
* Product Line - The product that the user is subscribed to (Security
Essentials, Security Complete, ...)
* essSecurity - New plugin with code that only runs for ESS offer
(non-serverless).
* App Feature - A security solution feature or group of features that
can be disabled for a product line. It can be mapped to PLIs (`Alert
Triage`, `Osquery`, `Cases` , ... ).
* Capability - A string that when present represents that the user can
access a given feature. A capability could be of the type UI or API
(`read_cases`, `crud_cases`, ...).
### Current architecture
### New architecture
### How does it work?
Every serverless product line (endpointEssentials, cloud essentials) can
define which features are enabled:
69d0fc15f4/x-pack/plugins/serverless_security/common/pli/pli_config.ts (L12-L19)
For ESS (non-serverless) offer we enable all features by default.
69d0fc15f4/x-pack/plugins/ess_security/server/constants.ts (L10-L13)
A feature can define privileges:
69d0fc15f4/x-pack/plugins/security_solution/server/lib/app_features/security_kibana_features.ts (L177-L185)
When the feature is enabled the privileges get merged into the base
config and injected into kibana features.
69d0fc15f4/x-pack/plugins/security_solution/server/lib/app_features/app_features.ts (L61-L70)
### TODO
- [x] lazy load these components
- [x] Add unit test to:
- ~SecurityRoutePageWrapper
x-pack/plugins/security_solution/public/common/components/security_route_page_wrapper/index.tsx~
-
~x-pack/plugins/security_solution/public/common/hooks/use_upselling.ts~
-
~x-pack/plugins/security_solution/public/common/lib/capabilities/has_capabilities.ts~
-
~x-pack/plugins/security_solution/public/common/lib/upsellings/upselling_service.ts~
- ~x-pack/plugins/serverless_security/common/pli/pli_features.ts~
-
~x-pack/plugins/serverless_security/public/components/upselling/register_upsellings.tsx~
-
~x-pack/plugins/security_solution/server/lib/app_features/app_features.ts~
### Checklist
Delete any items that are not applicable to this PR.
- [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
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
