This PR adds a new feature for streams to control whether the UI and API
is available.
Changes:
* Add the feature with two privileges (`show` and `manage_assets`)
* Can be configured with the classic `none`/`read`/`all` so it's
automatically aligned with serverless editor/viewer permissions
* None also means the app is not shown - to do this, the existing
`status$` observable also looks for at least the `streams.show`
capability
* Only guards changes to the linked dashboards - changes to the
Elasticsearch level are still delegated to the Elasticsearch-level
permissions of the user
* This happens on the UI level (disabled button and dashboard selection
on the dashboard page)
* and on the API level (all endpoints that can change linked dashboards
require the permission)
# Questions
* Not sure about the name `manage_assets` - maybe it should be something
else
* Not sure about how the queries stuff should work - @kdelemme anything
we should do in this area?
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Implements the access controls for SIEM rule migrations.
## API changes
- All API routes have been secured with "SIEM Migration" feature checks
- Start migration API route now checks if the user has privileges to use
the connector ID received
## UI changes
### Onboarding SIEM migrations
- AI Connector selection
- Actions & Connectors: Read -> This privilege allows reading and
selecting a connector
Otherwise, we show a callout with the missing privileges:
- Create a migration
- Security All -> Main Security read & write access
- Siem Migrations All -> new feature under the Security catalog
- Actions & Connectors: Read -> This privilege allows connector
execution for LLM calls
Otherwise, we show a callout with the missing privileges:
### Rule Translations page
- Minimum privileges to make the page accessible (read access):
- Security Read -> Main Security read access
- Siem Migrations All -> new feature under the Security catalog
Otherwise, we hide the link in the navigation and display the generic
empty state if accessed:
- To successfully install rules the following privileges are also
required (write access):
- Security All -> Main Security read & write access
- Index privileges for `.alerts*` pattern: _read, write,
view_index_metadata, manage_
- Index privileges for `lookup_*` pattern: _read_
Otherwise, we show a callout at the top of the page, this callout is
consistent with the one displayed on the Detection Rules page
(`/app/security/rules`)
- To retry rule translations (upload missing macros/lookups or retry
errors)
- Actions & Connectors: Read -> This privilege allows connector
execution for LLM calls
Otherwise, when attempted, we show a toast with the missing privilege.
## Other changes
- Technical preview label
- No connector selected toast
https://github.com/user-attachments/assets/e4900129-ae9c-413f-9a41-f7dca452e71d
## Fixes
- [Fixed] Not possible to select a connector when no connector is
selected:
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR reworks saved query privileges to rely solely on a single global
`savedQueryManagement` privilege, and eliminates app-specific overrides.
This change simplifies the security model for users, fixes bugginess in
the saved query management UI, and reduces code complexity associated
with maintaining two separate security mechanisms (app-specific
overrides and global saved query management privileges).
### Background
Saved queries allow users to store a combination of KQL or Lucene
queries, filters, and time filters to use across various applications in
Kibana. Access to saved query saved objects are currently granted by the
following feature privileges:
```json
[
"feature_discover.all",
"feature_dashboard.all",
"feature_savedQueryManagement.all",
"feature_maps.all",
"feature_savedObjectsManagement.all",
"feature_visualize.all"
]
```
There is also a saved query management UI within the Unified Search bar
shared by applications across Kibana:
<img
src="https://github.com/user-attachments/assets/e4a7539b-3dd4-4d47-9ff8-205281ef50e3"
width="500" />
The way access to this UI is managed in Kibana is currently confusing
and buggy:
- If a user has `feature_discover.all` and `feature_dashboard.all` they
will be able to load and save queries in Discover and Dashboard.
- If a user has `feature_discover.all` and `feature_dashboard.read` they
will be able to load queries in both Discover and Dashboard, but only
save queries in Discover (even though they have write access to the SO,
and API access). Instead they have to navigate to Discover to save a
query before navigating back to Dashboard to load it, making for a
confusing and frustrating UX.
- Access to the UI is even more confusing in apps not listed in the
above feature privileges (e.g. alerting, SLOs). Some of them chose to
check one of the above feature privileges, meaning users who otherwise
should have saved query access won't see the management UI if they don't
also have the exact feature privilege being checked. Other apps just
always show the management UI, leading to bugs and failures when users
without one of the above feature privileges attempt to save queries.
### Existing improvements
In v8.11.0, we introduced a new ["Saved Query
Management"](https://github.com/elastic/kibana/pull/166937) privilege,
allowing users to access saved queries across all of Kibana with a
single global privilege:
<img
src="https://github.com/user-attachments/assets/ccbe79a4-bd0b-4ed6-89c9-117cc1f99ee2"
width="600" />
When this privilege is added to a role, it solves the
`feature_discover.all` and `feature_dashboard.read` issue mentioned
above. However, it does not fix any of the mentioned issues for roles
without the new privilege. We have so far postponed further improvements
to avoid a breaking change.
### Approach
To fully resolve these issues and migrate to a single global privilege,
these changes have been made:
- Remove saved query SO access from all application feature privileges
and instead only allow access through the global saved query management
privilege.
- Stop relying on application feature privileges for toggling the saved
query management UI, and instead rely on the global privilege.
To implement this with minimal breaking changes, we've used the Kibana
privilege migration framework. This allows us to seamlessly migrate
existing roles containing feature privileges that currently provide
access to saved queries, ensuring they are assigned the global saved
query management privilege on upgrade.
As a result, we had to deprecate the following feature privileges,
replacing them with V2 privileges without saved query SO access:
```json
[
"feature_discover.all",
"feature_dashboard.all",
"feature_maps.all",
"feature_visualize.all"
]
```
Each area of code that currently relies on any of these feature
privileges had to be updated to instead access `feature_X_V2` instead
(as well as future code).
This PR still introduces a minor breaking change, since users who have
`feature_discover.all` and `feature_dashboard.read` are now able to save
queries in Dashboard after upgrade, but we believe this is a better UX
(and likely the expected one) and worth a small breaking change.
### Testing
- All existing privileges should continue to work as they do now,
including deprecated V1 feature privileges and customized serverless
privileges. There should be no changes for existing user roles apart
from the minor breaking change outlined above.
- Check that code changes in your area don't introduce breaking changes
to existing behaviour. Many of the changes are just updating client UI
capabilities code from `feature.privilege` to `feature_v2.privilege`,
which is backward compatible.
- The `savedQueryManagement` feature should now globally control access
to saved query management in Unified Search for all new user roles.
Regardless of privileges for Discover, Dashboard, Maps, or Visualize,
new user roles should follow this behaviour:
- If `savedQueryManagement` is `none`, the user cannot see or access the
saved query management UI or APIs.
- If `savedQueryManagement` is `read`, the user can load queries from
the UI and access read APIs, but cannot save queries from the UI or make
changes to queries through APIs.
- If `savedQueryManagement` is `all`, the user can both load and save
queries from the UI and through APIs.
### Checklist
- [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]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [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
- [ ] 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)
- [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.
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [x] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
### Identify risks
This PR risks introducing unintended breaking changes to user privileges
related to saved queries if the deprecated features have not been
properly migrated, and users could gain or lose access to saved query
management on upgrade. This would be bad if it happened, but not overly
severe since it wouldn't grant them access to any ES data they couldn't
previously access (only query saved objects). We have automated testing
in place to help ensure features have been migrated correctly, but the
scope of these changes are broad and touch many places in the codebase.
Additionally, the UI capabilities types are not very strict, and are
referenced with string paths in many places, which makes changing them
riskier than changing strictly typed code. A combination of regex
searches and temporarily modifying the `Capabilities` type to cause type
errors for deprecated privileges was used to identify references in
code. Reviewers should consider if there are any other ways that UI
capabilities can be referenced which were not addressed in this PR.
Our automated tests already help mitigate the risk, but it's important
that code owners thoroughly review the changes in their area and
consider if they could have unintended consequences. The Platform
Security team should also review this PR thoroughly, especially since
some changes were made to platform code around privilege handling. The
Data Discovery team will also manually test the behaviour when upgrading
existing user roles with deprecated feature privileges as part of 9.0
upgrade testing.
---------
Co-authored-by: Matthias Wilhelm <matthias.wilhelm@elastic.co>
Co-authored-by: Matthias Wilhelm <ankertal@gmail.com>
Co-authored-by: Aleh Zasypkin <aleh.zasypkin@gmail.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: “jeramysoucy” <jeramy.soucy@elastic.co>
This PR enables the feature flag for workflow insights, activates defend
insights within the Assistant scope, and aligns the tests accordingly.
The added privileges originate from [this
PR](https://github.com/elastic/kibana/pull/205088).
## Summary
Epic: https://github.com/elastic/security-team/issues/7998
In this PR we're breaking out the `timeline` and `notes` features into
their own feature privilege definition. Previously, access to both
features was granted implicitly through the `siem` feature. However, we
found that this level of access control is not sufficient for all
clients who wanted a more fine-grained way to grant access to parts of
security solution.
In order to break out `timeline` and `notes` from `siem`, we had to
deprecate it feature privilege definition for. That is why you'll find
plenty of changes of `siem` to `siemV2` in this PR. We're making use of
the feature privilege's `replacedBy` functionality, allowing for a
seamless migration of deprecated roles.
This means that roles that previously granted `siem.all` are now granted
`siemV2.all`, `timeline.all` and `notes.all` (same for `*.read`).
Existing users are not impacted and should all still have the correct
access. We added tests to make sure this is working as expected.
Alongside the `ui` privileges, this PR also adds dedicated API tags.
Those tags haven been added to the new and previous version of the
privilege definitions to allow for a clean migration:
```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>
Part of https://github.com/elastic/kibana/issues/180908
## Summary
**EDR Connector Subfeature Privilege**
This PR creates a new EDR connector sub-feature privilege under the read
privilege for connectors. The read privilege currently allows users to
execute connectors, and this new privilege will limit some of the
connectors that can be executed. When the EDR privilege is turned on,
users will be able to execute EDR connectors, and when it is off they
will not execute. This new privilege includes SentinelOne and
Crowdstrike connectors.
To determine which connectors are considered EDR connectors, we
leverage`getKibanaPrivileges` in the connector type definition. I
removed the restrictions to use this field only for system actions and
renamed `getSystemActionKibanaPrivileges` to
`getActionKibanaPrivileges`. I also added a field, `subFeatureType `, to
the connector type definition to help disable testing/executing an
connectors that are restricted under a sub-feature.
**EDR Connector Execution for Testing**
The execution of EDR connectors using the API is limited to a single
sub-action for testing purposes. This ensures users can still
configure/test EDR connectors. In a separate
[PR](https://github.com/elastic/kibana/pull/204804), I added back the
SentinelOne and Crowdstrike params UIs with options restricted to one
sub-action.
**Rule API and Feature Configuration Updates**
Validation has been added to the rule APIs to enforce restrictions on
adding EDR connectors. The connector feature configuration has been
updated to include a new feature ID, EdrForSecurityFeature, which
ensures that EDR connectors are hidden on the rule form.
Note: I saw that EDR connectors are also temporarily restricted in the
Security Solution UI. To streamline this, I removed the
`isBidirectionalConnectorType` check in `action_type_registry.ts`.
Instead, I removed `SecurityConnectorFeatureId` from the
`supportedFeatureIds` of the SentinelOne connector type definition.
### Checklist
Check the PR satisfies following conditions.
- [ ] [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
## To test
**EDR Connector Subfeature Privilege**
1. Create a new role and disable EDR connectors under the Actions and
Connectors privilege
2. Create a new user and assign that role to user
3. Create a Sentinel One connector (It doesn't need to work, you can use
fake values for the url and token)
4. Login as the new user and run the following in Dev Tools to verify
that you aren't authorized execute the Sentinel One connector
```
POST kbn:/api/actions/connector/$CONNECTOR_ID/_execute
{
"params": {
"subAction": "getAgents",
"subActionParams": {}
}
}
```
7. Update the role to enable EDR connectors and repeat the steps to
verify that you are authorized to run the connector. (It will fail but
verify it's not Unauthorized)
**EDR Connector Execution for Testing**
1. Enable the EDR connectors privilege in the role you created above and
log in as the user you created above.
2. Run the following in Dev Tools to verify that you are authorized
execute the Sentinel One connector using only the `getAgents`
sub-action. (It will fail but verify it's not `Unauthorized`)
```
POST kbn:/api/actions/connector/$CONNECTOR_ID/_execute
{
"params": {
"subAction": "getAgents",
"subActionParams": {}
}
}
```
3. Run it again but replace the `subAction` with `isolateHost`. Verify
that you get an unauthorized error.
**Rule API and Feature Configuration Updates**
1. 1. Enable the EDR connectors privilege in the role you created above
and log in as the user you created above.
2. Go to Stack Management
3. Try to create a rule, and verify that you don't see the SentinelOne
connector.
4. Try to create a rule using the API and add your SentinelOne
connector, verify that the API throws an error.
```
POST kbn:/api/alerting/rule
{
"tags": [],
"params": {},
"schedule": {
"interval": "1m"
},
"consumer": "alerts",
"name": "Always firing rule",
"rule_type_id": "example.always-firing",
"actions": [
{
"group": "small",
"id": "$CONNECTOR_ID",
"params": {
"subAction": "isolateAgent",
"subActionParams": {}
},
"frequency": {
"notify_when": "onActionGroupChange",
"throttle": null,
"summary": false
}
}
],
"alert_delay": {
"active": 1
}
}
```
5. You can test the same behaviors when trying to add a SentinelOne
connector to existing rules.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Moved Search Applications & Behavioral Analytics from the base
KibanaFeature to their own so that they can be controlled independently
from other parts of the search solution.
### Checklist
- [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)
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
This PR discontinues Reporting from having dual models for determining
the privilege to generate a report, and uses Kibana feature privileges
as the single model that controls those privileges.
### Changes
1. Removes all logic that is based on following settings:
* `xpack.reporting.roles.enabled`
* `xpack.reporting.roles.allow`
The settings are still supported, but any features that use the settings
are removed.
2. Removes the detection of the settings from the Upgrade Assistant
integration
### Release note
The default system of granting users the privilege to generate reports
has changed. Rather than assigning users the `reporting_user` role,
administrators should create a custom role that grants report-creation
privileges using Kibana application privileges.
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [x]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [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.
Correlates with https://elasticco.atlassian.net/browse/ES-9856: assign
the built-in `reporting_user` role the necessary Kibana application
privileges, and make the role not marked as deprecated.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR adds:
* Some basic features and privileges for the EEM app
* A function that sets up an index with a template for the new
definitions
* 4 API endpoints to read and create entity types and sources
* `POST /internal/entities/v2/definitions/types`
* `GET /internal/entities/v2/definitions/types`
* `POST /internal/entities/v2/definitions/sources`
* `GET /internal/entities/v2/definitions/sources`
* Some v2 shuffling around of code
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Maxim Palenov <maxim.palenov@elastic.co>
## Summary
Fixes https://github.com/elastic/kibana/issues/200899
Added Synthetics Sub-feature for managing private locations !!
User can configure a sub feature in a role under synthetics to allow
managing private locations ,
with role API it will be with
```
{
kibana: [
{
feature: {
uptime: [
'minimal_all',
'can_manage_private_locations',
],
},
spaces: ['*'],
},
],
}
```
<img width="1728" alt="image"
src="https://github.com/user-attachments/assets/f842da22-9c82-43d0-ad34-c6e19ea187c6">
Create/delete actions on UI will be disabled
<img width="1728" alt="image"
src="https://github.com/user-attachments/assets/1a164d85-357b-42f3-ae15-0682b2db6c75">
## Release note
If you have already modified sub feature for the synthetics/uptime
feature to disable user access for using elastic managed location,
addition of this feature means, they will also will not be able to
manage(add/delete) private locations. Though this will not impact usage
of private locations in monitors. If you want those users to have
ability to add/delete new private locations, you can enable that by
toggle this feature in role ui or via api.
## Summary
This pr adds 2 new sub feature permissions to the cases plugin in
stack/security/observability, that behave as follows. The first is for
controlling the ability to reopen cases. When Cases has the read
permission, and the reopen permission is not enabled, users have
permissions as before. When enabled, users can move cases from closed to
open/in progress, but nothing else. If a user has all and this
permission, they can do anything as before, if the option is unselected,
they can change case properties, and change a case from open to
anything, in progress to anything, but if the case is closed, are unable
to reopen it.
The 2nd permission is 'Add comment'. When enabled and the user has case
read permissions, users can add comments, but not make any other changes
to the case. When the user has read and this deselected, read functions
as before. When a user has this permission and cases is all, this
functions as all. When they have all but this permission is deselected,
the user can do everything normally, except add cases comments.
### Checklist
- [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)
- [ ]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [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: Michael Olorunnisola <michael.olorunnisola@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Closes https://github.com/elastic/kibana/issues/156898
This PR adds a new sub-feature role to APM, which is the ability to
write into the settings page: for UI, `settings:save`, for API,
`apm_settings_write`.
The other changes are adapting to use this new permission.
## How to test
1. Go under `Stack Management` -> `Roles` and create a new custom role.
3. For Kibana, select `All spaces` for the space selector, and
`Customize`, you can get all the permissions you need.
4. Go into `Observability` and `APM and User Experience`.
5. Select `Read` and save the role.
6. Create a new user and assign that role and also the `viewer` role.
7. Login with an incognito / different browser into the new user.
8. Go into `APM` -> `Settings`, WARNING: if you are not able to see
settings is because you don't have data, run `node scripts/synthtrace
many_services.ts --live --clean`.
9. You should not be able to change the configuration on each tab.
10. Change the role privileges to have `Read` but with write access.
11. Test it, you should be able to modify the settings.
12. Do the same with `All` with and without the write permissions.
## Demo
https://github.com/user-attachments/assets/5c1b6c33-4c2c-4616-bfe2-5b4bdc414e6a
closes [#3874](https://github.com/elastic/observability-dev/issues/3874)
## 📝 Summary
This PR adds new kibana privilege feature to control access to `Data Set
Quality` page under Stack Management's `Data` section.
Had to fix a lot of tests since the `kibana_admin` role gets access by
default to all kibana features one of which now is the `Data Set
Quality` page. At the same time this made the `Data` section visible to
any user with `kibana_admin` role.
## 🎥 Demo
https://github.com/user-attachments/assets/ce8c8110-f6f4-44b8-a4e7-5f2dd3deda66
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This change is the implementation of the `Kibana Privilege Migrations`
proposal/RFC and provides a framework that allows developers to replace
an existing feature with a new one that has the desired configuration
while teaching the platform how the privileges of the deprecated feature
can be represented by non-deprecated ones. This approach avoids
introducing breaking changes for users who still rely on the deprecated
privileges in their existing roles and any automation.
Among the use cases the framework is supposed to handle, the most common
are the following:
* Changing a feature ID from `Alpha` to `Beta`
* Splitting a feature `Alpha` into two features, `Beta` and `Gamma`
* Moving a capability between privileges within a feature (top-level or
sub-feature)
* Consolidating capabilities across independent features
## Scope
This PR includes only the core functionality proposed in the RFC and
most of the necessary guardrails (tests, early validations, etc.) to
help engineers start planning and implementing their migrations as soon
as possible. The following functionality will be added in follow-ups or
once we collect enough feedback:
* Telemetry
* Developer documentation
* UI enhancements (highlighting roles with deprecated privileges and
manual migration actions)
## Framework
The steps below use a scenario where a feature `Alpha` should be split
into two other features `Beta` and `Gamma` as an example.
### Step 1: Create new features with the desired privileges
First of all, define new feature or features with the desired
configuration as you'd do before. There are no constraints here.
<details>
<summary>Click to see the code</summary>
```ts
deps.features.registerKibanaFeature({
id: 'feature_beta',
name: 'Feature Beta',
privileges: {
all: {
savedObject: { all: ['saved_object_1'], read: [] },
ui: ['ui_all'],
api: ['api_all'],
… omitted for brevity …
},
read: {
savedObject: { all: [], read: ['saved_object_1'] },
ui: ['ui_read'],
api: ['api_read'],
… omitted for brevity …
},
},
… omitted for brevity …
});
deps.features.registerKibanaFeature({
id: 'feature_gamma',
name: 'Feature Gamma',
privileges: {
all: {
savedObject: { all: ['saved_object_2'], read: [] },
ui: ['ui_all'],
// Note that Feature Gamma, unlike Features Alpha and Beta doesn't provide any API access tags
… omitted for brevity …
},
read: {
savedObject: { all: [], read: ['saved_object_2'] },
ui: ['ui_read'],
// Note that Feature Gamma, unlike Features Alpha and Beta doesn't provide any API access tags
… omitted for brevity …
},
},
… omitted for brevity …
});
```
</details>
### Step 2: Mark existing feature as deprecated
Once a feature is marked as deprecated, it should essentially be treated
as frozen for backward compatibility reasons. Deprecated features will
no longer be available through the Kibana role management UI and will be
replaced with non-deprecated privileges.
Deprecated privileges will still be accepted if the role is created or
updated via the Kibana role management APIs to avoid disrupting existing
user automation.
To avoid breaking existing roles that reference privileges provided by
the deprecated features, Kibana will continue registering these
privileges as Elasticsearch application privileges.
<details>
<summary>Click to see the code</summary>
```ts
deps.features.registerKibanaFeature({
// This is a new `KibanaFeature` property available during feature registration.
deprecated: {
// User-facing justification for privilege deprecation that we can display
// to the user when we ask them to perform role migration.
notice: i18n.translate('xpack.security...', {
defaultMessage: "Feature Alpha is deprecated, refer to {link}...",
values: { link: docLinks.links.security.deprecatedFeatureAlpha },
})
},
// Feature id should stay unchanged, and it's not possible to reuse it.
id: 'feature_alpha',
name: 'Feature Alpha (DEPRECATED)',
privileges: {
all: {
savedObject: { all: ['saved_object_1', 'saved_object_2'], read: [] },
ui: ['ui_all'],
api: ['api_all'],
… omitted for brevity …
},
read: {
savedObject: { all: [], read: ['saved_object_1', 'saved_object_2'] },
ui: ['ui_read'],
api: ['api_read'],
… omitted for brevity …
},
},
… omitted for brevity …
});
```
</details>
### Step 3: Map deprecated feature’s privileges to the privileges of the
non-deprecated features
The important requirement for a successful migration from a deprecated
feature to a new feature or features is that it should be possible to
express **any combination** of the deprecated feature and sub-feature
privileges with the feature or sub-feature privileges of non-deprecated
features. This way, while editing a role with deprecated feature
privileges in the UI, the admin will be interacting with new privileges
as if they were creating a new role from scratch, maintaining
consistency.
The relationship between the privileges of the deprecated feature and
the privileges of the features that are supposed to replace them is
expressed with a new `replacedBy` property available on the privileges
of the deprecated feature.
<details>
<summary>Click to see the code</summary>
```ts
deps.features.registerKibanaFeature({
// This is a new `KibanaFeature` property available during feature registration.
deprecated: {
// User-facing justification for privilege deprecation that we can display
// to the user when we ask them to perform role migration.
notice: i18n.translate('xpack.security...', {
defaultMessage: "Feature Alpha is deprecated, refer to {link}...",
values: { link: docLinks.links.security.deprecatedFeatureAlpha },
})
},
// Feature id should stay unchanged, and it's not possible to reuse it.
id: 'feature_alpha',
name: 'Feature Alpha (DEPRECATED)',
privileges: {
all: {
savedObject: { all: ['saved_object_1', 'saved_object_2'], read: [] },
ui: ['ui_all'],
api: ['api_all'],
replacedBy: [
{ feature: 'feature_beta', privileges: ['all'] },
{ feature: 'feature_gamma', privileges: ['all'] },
],
… omitted for brevity …
},
read: {
savedObject: { all: [], read: ['saved_object_1', 'saved_object_2'] },
ui: ['ui_read'],
api: ['api_read'],
replacedBy: [
{ feature: 'feature_beta', privileges: ['read'] },
{ feature: 'feature_gamma', privileges: ['read'] },
],
… omitted for brevity …
},
},
… omitted for brevity …
});
```
</details>
### Step 4: Adjust the code to rely only on new, non-deprecated features
Special care should be taken if the replacement privileges cannot reuse
the API access tags from the deprecated privileges and introduce new
tags that will be applied to the same API endpoints. In this case,
developers should replace the API access tags of the deprecated
privileges with the corresponding tags provided by the replacement
privileges. This is necessary because API endpoints can only be accessed
if the user privileges cover all the tags listed in the API endpoint
definition, and without these changes, existing roles referencing
deprecated privileges won’t be able to access those endpoints.
The UI capabilities are handled slightly differently because they are
always prefixed with the feature ID. When migrating to new features with
new IDs, the code that interacts with UI capabilities will be updated to
use these new feature IDs.
<details>
<summary>Click to see the code</summary>
```ts
// BEFORE deprecation/migration
// 1. Feature Alpha defition (not deprecated yet)
deps.features.registerKibanaFeature({
id: 'feature_alpha',
privileges: {
all: {
api: ['api_all'],
… omitted for brevity …
},
},
… omitted for brevity …
});
// 2. Route protected by `all` privilege of the Feature Alpha
router.post(
{ path: '/api/domain/my_api', options: { tags: ['access:api_all'] } },
async (_context, request, response) => {}
);
// AFTER deprecation/migration
// 1. Feature Alpha defition (deprecated, with updated API tags)
deps.features.registerKibanaFeature({
deprecated: …,
id: 'feature_alpha',
privileges: {
all: {
api: ['api_all_v2'],
replacedBy: [
{ feature: 'feature_beta', privileges: ['all'] },
],
… omitted for brevity …
},
},
… omitted for brevity …
});
// 2. Feature Beta defition (new)
deps.features.registerKibanaFeature({
id: 'feature_beta',
privileges: {
all: {
api: ['api_all_v2'],
… omitted for brevity …
}
},
… omitted for brevity …
});
// 3. Route protected by `all` privilege of the Feature Alpha OR Feature Beta
router.post(
{ path: '/api/domain/my_api', options: { tags: ['access:api_all_v2'] } },
async (_context, request, response) => {}
);
----
// ❌ Old client-side code (supports only deprecated privileges)
if (capabilities.feature_alpha.ui_all) {
… omitted for brevity …
}
// ✅ New client-side code (will work for **both** new and deprecated privileges)
if (capabilities.feature_beta.ui_all) {
… omitted for brevity …
}
```
</details>
## How to test
The code introduces a set of API integration tests that are designed to
validate whether the privilege mapping between deprecated and
replacement privileges maintains backward compatibility.
You can run the test server with the following config to register a
number of [example deprecated
features](https://github.com/elastic/kibana/pull/186800/files#diff-d887981d43bbe30cda039340b906b0fa7649ba80230be4de8eda326036f10f6fR20-R49)(`x-pack/test/security_api_integration/plugins/features_provider/server/index.ts`)
and the features that replace them, to see the framework in action:
```bash
node scripts/functional_tests_server.js --config x-pack/test/security_api_integration/features.config.ts
```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This implements RBAC properly for Search. We no longer rely on the
enterprise search node to limit access to Search, so except for App
Search and Workplace Search. That means we need proper Kibana features
to manage RBAC, which this adds: one for Search and a separate one for
Relevance as that feature is guarded by an Enterprise license.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## [Security Solution] [Attack discovery] Attack Discovery RBAC / Display an upgrade CTA for the serverless essentials product tier
### Summary
This PR adds Role Based Access Control (RBAC) to Attack discovery.
Security users may enable or disable the new `Attack Discovery` RBAC feature shown in the figure below:
_Above: The new `Attack discovery` RBAC feature_
It is possible to for example, configure a custom role that enables Attack discovery, but disables the assistant, as illustrated by the table below:
| Role | License | Navigation visible | Show upsell | Upsell has actions | View in assistant enabled |
|-------------------------------------------|------------|--------------------|-------------|--------------------|---------------------------|
| `has_attack_discovery_all_assistant_none` | Basic | ✅ | ✅ | ✅ | ❌ |
| `has_attack_discovery_all_assistant_none` | Trial | ✅ | ❌ | ❌ | ❌ |
| `has_attack_discovery_all_assistant_none` | Platinum | ✅ | ✅ | ✅ | ❌ |
| `has_attack_discovery_all_assistant_none` | Enterprise | ✅ | ❌ | ❌ | ❌ |
_Above: An example role that enables Attack discovery, but disables the assistant_
See the `Desk Testing` section of this PR for details.
This PR also fixes an issue where Attack discovery does not display an upgrade call to action (CTA) for the serverless _essentials_ product tier, per the before and after screenshots below:
#### Before
_Above: Before the fix, an upgrade CTA is NOT displayed for the serverless essentials product tier_
#### After
_Above: After the fix, an upgrade CTA is displayed for the serverless essentials product tier_
The fix above is implemented by adopting the upselling framework.
### New Feature ID
This PR adds a new Feature ID for attack discovery:
```typescript
export const ATTACK_DISCOVERY_FEATURE_ID = 'securitySolutionAttackDiscovery' as const;
```
in `x-pack/packages/security-solution/features/src/constants.ts`
### Upselling framework usage
This PR updates the Attack discovery page to use the upselling framework via the following summarized steps:
1. Removed the branching logic from `x-pack/plugins/security_solution/public/attack_discovery/pages/upgrade/index.tsx`, and moved the component to an upselling `section` component in `x-pack/packages/security-solution/upselling/sections/attack_discovery/index.tsx`, where the component was renamed to `AttackDiscoveryUpsellingSection`.
This `section` component handles (just) the styling of the upselling message and actions (by itself, without the page wrapper), and receives the following props:
```typescript
interface Props {
actions?: React.ReactNode;
availabilityMessage: string;
upgradeMessage: string;
}
```
The self managed and serverless-specific actions and `i18n` messages are passed down via the components described in the later steps below.
2. Removed all previous references to the `Upgrade` component (and references to `useProductTypes`) from the Attack discovery page in `x-pack/plugins/security_solution/public/attack_discovery/pages/index.tsx`, because the framework manages the upgrade case instead of the page itself.
3. Created an upselling `page` component `AttackDiscoveryUpsellingPage` in `x-pack/packages/security-solution/upselling/pages/attack_discovery/index.tsx`.
This component handles (just) the styling of the _page_ that wraps the Attack discovery `section`. It passes the same props to the previously described `AttackDiscoveryUpsellingSection` component.
4. Created a self-managed-specific `AttackDiscoveryUpsellingPageESS` component in `x-pack/plugins/security_solution_ess/public/upselling/pages/attack_discovery/index.tsx`
This component passes self-managed-specific upgrade action buttons / links and `i18n` strings to the previously described `AttackDiscoveryUpsellingPage`
5. Also for self managed, added a new `AttackDiscoveryUpsellingPageLazy` component to the existing file: `x-pack/plugins/security_solution_ess/public/upselling/lazy_upselling.tsx`
This component lazy loads the previously described `AttackDiscoveryUpsellingPageESS` component.
6. Added registration for the previously described `AttackDiscoveryUpsellingPageLazy` component to the existing `UpsellingPages` section in `x-pack/plugins/security_solution_ess/public/upselling/register_upsellings.tsx` with a `minimumLicenseRequired` of `enterprise`:
```
minimumLicenseRequired: 'enterprise',
```
7. Created a serverless-specific `AttackDiscoveryUpsellingPageServerless` component in `x-pack/plugins/security_solution_serverless/public/upselling/pages/attack_discovery/index.tsx`
This component passes serverless-specific `i18n` messages to the platform agnostic `AttackDiscoveryUpsellingPage` component.
8. Also for serverless, added a new `AttackDiscoveryUpsellingPageLazy` component to the existing file: `x-pack/plugins/security_solution_serverless/public/upselling/lazy_upselling.tsx`
9. Added registration for the previously described `AttackDiscoveryUpsellingPageLazy` component to the existing `upsellingPages` section in `x-pack/plugins/security_solution_serverless/public/upselling/upsellings.tsx` with the `assistant` PLI:
```
pli: ProductFeatureKey.assistant,
```
10. Added the `${ASSISTANT_FEATURE_ID}.ai-assistant` capability as an OR condition (via nested array, per the [framework](https://github.com/elastic/kibana/blob/main/x-pack/plugins/security_solution/public/common/lib/capabilities/has_capabilities.ts#L11-L22)) to the Attack discovery link in `x-pack/plugins/security_solution/public/attack_discovery/links.ts`. This addition enables the security route wrapper to check for upselling pages in serverless:
```
capabilities: [[`${SERVER_APP_ID}.show`, `${ASSISTANT_FEATURE_ID}.ai-assistant`]],
```
11. Added `licenseType: 'enterprise'` to the Attack discovery link in `x-pack/plugins/security_solution/public/attack_discovery/links.ts` to require an `enterprise` license for self managed
### Upgrade CTA gallery
The screenshots in this section document the CTA (or Welcome message when the feature is licensed) displayed for various license levels after the fix:
#### Users with the `None` privilege
If users with the `None` privilege manually enter an Attack discovery URL, e.g. `http://localhost:5601/app/security/attack_discovery`, the framework will display the following error prompt:
#### Self managed BASIC
#### Self managed PLATINUM
#### Self managed TRIAL
#### Self managed ENTERPRISE
#### Serverless ESSENTIALS
#### Serverless COMPLETE
## Desk Testing
### Severless: Desk testing (just) the upgrade CTA
Reproduction steps:
1) Comment-out any preconfigured connectors in `config/kibana.dev.yml`
2) Edit the configuration of `config/serverless.security.yml` to enable the `essentials` product tier:
```yaml
xpack.securitySolutionServerless.productTypes:
[
{ product_line: 'security', product_tier: 'essentials' }
]
```
3) Start Elasticsearch
```sh
yarn es serverless --projectType security
```
4) Start a development instance of Kibana
```
yarn start --serverless=security --no-base-path
```
5) Navigate to Security > Attack discovery
**Expected result**
- An upgrade CTA is displayed, as illustrated by the _after_ screenshot below:
- The video tour is NOT displayed for serverless, as noted in the [original PR](https://github.com/elastic/kibana/pull/182605#issuecomment-2100607857)
**Actual result**
- An upgrade CTA is NOT displayed, as illustrated by the _before_ screenshot below:
### Desk testing Self Managed
To desk test self manged, we will:
1) Create (three) roles for testing
2) Create (three) users assigned to the roles
3) Test each role at `Basic`, `Trial`, `Platinum`, and `Enterprise` levels to verify:
- `Attack discovery` link visibility in the Security solution navigation
- Visibility of the upsell empty prompt for license levels where Attack discovery is unavailable
- The upsell empty prompt includes the `Subscription plans` and `Manage license` actions
- When Attack discoveries are generated, the `View in Ai Assistant` button and popover menu action are enabled / disabled, based on availability of the `AI Assistant` feature
#### Creating (three) roles for testing
In this section, we will start a new (development) self managed deployment, and create the following three roles via Kibana Dev Tools:
- `has_attack_discovery_all_assistant_all`
- `has_attack_discovery_all_assistant_none`
- `has_attack_discovery_none_assistant_all`
To start the deployment and create the roles:
1) Add a pre-configured GenAI connector to `config/kibana.dev.yml`
2) Start a new (development) instance of Elasticsearch:
```sh
yarn es snapshot -E path.data=/Users/$USERNAME/data-2024-07-31a
```
3) Start a local (development) instance of Kibana:
```
yarn start --no-base-path
````
4) Login to Kibana as the `elastic` user
5) Generate some alerts
6) Navigate to Dev Tools
7) Execute the following three API calls to create the roles:
<details><summary>PUT /_security/role/has_attack_discovery_all_assistant_all</summary>
<p>
``` ts
PUT /_security/role/has_attack_discovery_all_assistant_all
{
"cluster": [
"all"
],
"indices": [
{
"names": [
"*"
],
"privileges": [
"all"
],
"field_security": {
"grant": [
"*"
],
"except": []
},
"allow_restricted_indices": false
}
],
"applications": [
{
"application": "kibana-.kibana",
"privileges": [
"feature_securitySolutionAssistant.minimal_all",
"feature_securitySolutionAttackDiscovery.minimal_all",
"feature_siem.all",
"feature_securitySolutionCases.all",
"feature_actions.all"
],
"resources": [
"*"
]
}
],
"run_as": [],
"metadata": {},
"transient_metadata": {
"enabled": true
}
}
```
</p>
</details>
<details><summary>PUT /_security/role/has_attack_discovery_all_assistant_none</summary>
<p>
``` ts
PUT /_security/role/has_attack_discovery_all_assistant_none
{
"cluster": [
"all"
],
"indices": [
{
"names": [
"*"
],
"privileges": [
"all"
],
"field_security": {
"grant": [
"*"
],
"except": []
},
"allow_restricted_indices": false
}
],
"applications": [
{
"application": "kibana-.kibana",
"privileges": [
"feature_securitySolutionAttackDiscovery.minimal_all",
"feature_siem.all",
"feature_securitySolutionCases.all",
"feature_actions.all"
],
"resources": [
"*"
]
}
],
"run_as": [],
"metadata": {},
"transient_metadata": {
"enabled": true
}
}
```
</p>
</details>
<details><summary>PUT /_security/role/has_attack_discovery_none_assistant_all</summary>
<p>
``` ts
PUT /_security/role/has_attack_discovery_none_assistant_all
{
"cluster": [
"all"
],
"indices": [
{
"names": [
"*"
],
"privileges": [
"all"
],
"field_security": {
"grant": [
"*"
],
"except": []
},
"allow_restricted_indices": false
}
],
"applications": [
{
"application": "kibana-.kibana",
"privileges": [
"feature_securitySolutionAssistant.minimal_all",
"feature_siem.all",
"feature_securitySolutionCases.all",
"feature_actions.all"
],
"resources": [
"*"
]
}
],
"run_as": [],
"metadata": {},
"transient_metadata": {
"enabled": true
}
}
```
</p>
</details>
#### Creating (three) users assigned to the roles
In this section, we will create the following three users via Kibana Dev Tools using the API calls below (expand for details):
- `attack_discovery_all_assistant_all`
- `attack_discovery_all_assistant_none`
- `attack_discovery_none_assistant_all`
1) Navigate to Dev Tools
2) Execute the following three API calls to create the users:
<details><summary>POST /_security/user/attack_discovery_all_assistant_all</summary>
<p>
``` ts
POST /_security/user/attack_discovery_all_assistant_all
{
"username": "attack_discovery_all_assistant_all",
"password": "changeme",
"roles": [
"has_attack_discovery_all_assistant_all"
],
"full_name": "Attack Discovery All Assistant All",
"email": "user@example.com",
"metadata": {},
"enabled": true
}
```
</p>
</details>
<details><summary>POST /_security/user/attack_discovery_all_assistant_none</summary>
<p>
``` ts
POST /_security/user/attack_discovery_all_assistant_none
{
"username": "attack_discovery_all_assistant_none",
"password": "changeme",
"roles": [
"has_attack_discovery_all_assistant_none"
],
"full_name": "Attack Discovery All Assistant None",
"email": "user@example.com",
"metadata": {},
"enabled": true
}
```
</p>
</details>
<details><summary>POST /_security/user/attack_discovery_none_assistant_all</summary>
<p>
``` ts
POST /_security/user/attack_discovery_none_assistant_all
{
"username": "attack_discovery_none_assistant_all",
"password": "changeme",
"roles": [
"has_attack_discovery_none_assistant_all"
],
"full_name": "Attack Discovery None Assistant All",
"email": "user@example.com",
"metadata": {},
"enabled": true
}
```
</p>
</details>
#### Testing each role at `Basic`, `Trial`, `Platinum`, and `Enterprise` levels
In this section, we will test each of the self managed `Basic`, `Trial`, `Platinum`, and `Enterprise` license levels with the three roles we created for testing.
##### Testing the `has_attack_discovery_all_assistant_all` role
1) Login as the `attack_discovery_all_assistant_all` user
2) Navigate to the Security solution
3) For each of the `Basic`, `Trial`, `Platinum`, and `Enterprise` levels, verify your observations match the expected behavior in the table below:
| Role | License | Navigation visible | Show upsell | Upsell has actions | View in assistant enabled |
|------------------------------------------|------------|--------------------|-------------|--------------------|---------------------------|
| `has_attack_discovery_all_assistant_all` | Basic | ✅ | ✅ | ✅ | ❌ |
| `has_attack_discovery_all_assistant_all` | Trial | ✅ | ❌ | ❌ | ✅ |
| `has_attack_discovery_all_assistant_all` | Platinum | ✅ | ✅ | ✅ | ❌ |
| `has_attack_discovery_all_assistant_all` | Enterprise | ✅ | ❌ | ❌ | ✅ |
##### Testing the `has_attack_discovery_all_assistant_none` role
1) Login as the `attack_discovery_all_assistant_none` user
2) Navigate to the Security solution
3) For each of the `Basic`, `Trial`, `Platinum`, and `Enterprise` levels, verify your observations match the expected behavior in the table below:
| Role | License | Navigation visible | Show upsell | Upsell has actions | View in assistant enabled |
|-------------------------------------------|------------|--------------------|-------------|--------------------|---------------------------|
| `has_attack_discovery_all_assistant_none` | Basic | ✅ | ✅ | ✅ | ❌ |
| `has_attack_discovery_all_assistant_none` | Trial | ✅ | ❌ | ❌ | ❌ |
| `has_attack_discovery_all_assistant_none` | Platinum | ✅ | ✅ | ✅ | ❌ |
| `has_attack_discovery_all_assistant_none` | Enterprise | ✅ | ❌ | ❌ | ❌ |
##### Testing the `has_attack_discovery_none_assistant_all` role
1) Login as the `attack_discovery_none_assistant_all` user
2) Navigate to the Security solution
3) For each of the `Basic`, `Trial`, `Platinum`, and `Enterprise` levels, verify your observations match the expected behavior in the table below:
| Role | License | Navigation visible | Show upsell | Upsell has actions | View in assistant enabled |
|-------------------------------------------|------------|--------------------|-------------|--------------------|---------------------------|
| `has_attack_discovery_none_assistant_all` | Basic | ✅ | ✅ | ✅ | ❌ |
| `has_attack_discovery_none_assistant_all` | Trial | ❌ | ❌ | ❌ | ❌ |
| `has_attack_discovery_none_assistant_all` | Platinum | ✅ | ✅ | ✅ | ❌ |
| `has_attack_discovery_none_assistant_all` | Enterprise | ❌ | ❌ | ❌ | ❌ |
---------------------------------------------
### Serverless Testing
To desk test serverless, we will test the `essentials` and `complete` product tiers to verify:
- `Attack discovery` link visibility in the Security project navigation
- Visibility of the upsell empty prompt for license levels where Attack discovery is unavailable
- The upsell empty prompt does NOT include the `Subscription plans` and `Manage license` actions
- When Attack discoveries are generated, the `View in Ai Assistant` button and popover menu action are enabled
#### Essentials tier testing
1) Add a pre-configured GenAI connector to `config/kibana.dev.yml`
2) Edit the configuration of `config/serverless.security.yml` to enable the `essentials` product tier:
```yaml
xpack.securitySolutionServerless.productTypes:
[
{ product_line: 'security', product_tier: 'essentials' },
{ product_line: 'endpoint', product_tier: 'essentials' },
]
```
2) Start a new (development) instance of Elasticsearch:
```sh
yarn es serverless --clean --projectType security
```
3) Start a local (development) instance of Kibana:
```
yarn start --serverless=security --no-base-path
````
4) select the `admin` role
5) Generate some alerts
6) Verify your observations match the expected behavior in the table below:
| Role | Tier | Navigation visible | Show upsell | Upsell has actions | View in assistant enabled |
|-------------------------------|------------|--------------------|-------------|--------------------|---------------------------|
| `viewer` | essentials | ✅ | ✅ | ❌ | ❌ |
| `editor` | essentials | ✅ | ✅ | ❌ | ❌ |
| `t1_analyst` | essentials | ✅ | ✅ | ❌ | ❌ |
| `t2_analyst` | essentials | ✅ | ✅ | ❌ | ❌ |
| `t3_analyst` | essentials | ✅ | ✅ | ❌ | ❌ |
| `threat_intelligence_analyst` | essentials | ✅ | ✅ | ❌ | ❌ |
| `rule_author` | essentials | ✅ | ✅ | ❌ | ❌ |
| `soc_manager` | essentials | ✅ | ✅ | ❌ | ❌ |
| `detections_admin` | essentials | ✅ | ✅ | ❌ | ❌ |
| `platform_engineer` | essentials | ✅ | ✅ | ❌ | ❌ |
| `endpoint_operations_analyst` | essentials | ✅ | ✅ | ❌ | ❌ |
| `endpoint_policy_manager` | essentials | ✅ | ✅ | ❌ | ❌ |
| `admin` | essentials | ✅ | ✅ | ❌ | ❌ |
| `system_indices_superuser` | essentials | ✅ | ✅ | ❌ | ❌ |
### Complete tier testing
1) Stop the running Kibana server (from the previous Essentials tier testing)
2) Edit the configuration of `config/serverless.security.yml` to enable the `complete` product tier:
```yaml
xpack.securitySolutionServerless.productTypes:
[
{ product_line: 'security', product_tier: 'complete' },
{ product_line: 'endpoint', product_tier: 'complete' },
]
```
3) Restart a local (development) instance of Kibana:
```
yarn start --serverless=security --no-base-path
````
4) Verify your observations match the expected behavior in the table below:
| Role | Tier | Navigation visible | Show upsell | Upsell has actions | View in assistant enabled |
|-------------------------------|----------|--------------------|-------------|--------------------|---------------------------|
| `viewer` | complete | ✅ | ❌ | ❌ | ✅ |
| `editor` | complete | ✅ | ❌ | ❌ | ✅ |
| `t1_analyst` | complete | ✅ | ❌ | ❌ | ✅ |
| `t2_analyst` | complete | ✅ | ❌ | ❌ | ✅ |
| `t3_analyst` | complete | ✅ | ❌ | ❌ | ✅ |
| `threat_intelligence_analyst` | complete | ✅ | ❌ | ❌ | ✅ |
| `rule_author` | complete | ✅ | ❌ | ❌ | ✅ |
| `soc_manager` | complete | ✅ | ❌ | ❌ | ✅ |
| `detections_admin` | complete | ✅ | ❌ | ❌ | ✅ |
| `platform_engineer` | complete | ✅ | ❌ | ❌ | ✅ |
| `endpoint_operations_analyst` | complete | ✅ | ❌ | ❌ | ✅ |
| `endpoint_policy_manager` | complete | ✅ | ❌ | ❌ | ✅ |
| `admin` | complete | ✅ | ❌ | ❌ | ✅ |
| `system_indices_superuser` | complete | ✅ | ❌ | ❌ | ✅ |
Added new sub-feature to AI-Assistant which allows to grant user role
privilege to edit Anonymization fields:
<img width="761" alt="Screenshot 2024-04-11 at 7 29 50 PM"
src="d4358178-d8e9-4c68-b7d4-a19d2befa29b">
How to test:
1. Create user role, which has access to Security and Actions/Connectors
and AI Assistant.
2. Customize sub-feature privileges: Remove checkbox for Update
anonymization fields.
3. Save role.
4. Create/update existing user with the new role.
5. Go to Security AI Assistant settings and open Anonymization tab.
6. For the user role with removed privilege to edit anonymization, all
actionable buttons should be disabled. Button Save will remain enabled,
because it correspond to all Assistant settings.
7. Public API "/api/elastic_assistant/anonymization_fields/_bulk_action"
should return "Forbidden" 403 access error.
How it looks when no privilege for the user role:
<img width="771" alt="Screenshot 2024-04-12 at 10 12 34 AM"
src="7c3b6c92-12cb-46ae-8356-dc687c82726f">
@patrykkopycinski please adopt it after merging this PR to the new UX
---------
Co-authored-by: Garrett Spong <garrett.spong@elastic.co>
We've decided to keep this behind a feature flag for now since we have
bugs to iron out with Fleet's new permissions model, and we don't have
the option of going into technical preview first
## Summary
Resolve [#179546](https://github.com/elastic/kibana/issues/179546)
Enable subfeature privileges.
Added a message in the tooltip that feature is in technical preview.
<img width="788" alt="Screenshot 2024-04-03 at 2 28 54 PM"
src="cbc3f963-2b8c-40a7-8450-e5949ce4e19d">
## Release note
Add subfeatures privileges for Fleet, for Agents, Agent policies and
Settings, that feature is in technical preview and may be changed or
removed completely in a future release.
---------
Co-authored-by: Kyle Pollich <kyle.pollich@elastic.co>
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Julia Bardi <90178898+juliaElastic@users.noreply.github.com>
Resolves https://github.com/elastic/kibana/issues/169868
## Summary
Hides the query delay modal and sub feature privilege for non-serverless
projects until we onboard all rule types
### 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
### To verify
- Run a non serverless project and verify that you can't edit the query
delay settings in the rules settings modal
- Run a serverless project for search and observability to verify that
you can still edit and update the query delay settings
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Adds `All`/`None` RBAC for the Elastic AI Assistant within the Security
app via Kibana feature privileges, and also via serverless PLI App
Features for the Security `complete` product (see
https://github.com/elastic/security-team/issues/7023).
Added as high-level category to enable future support of sub-features
(included sample `Create Conversation` sub-feature plumbed as example).
<p align="center">
<img width="500"
src="b42ab3fe-65e1-49b9-a379-262f2438c0eb"
/>
</p>
Note: Since [`minimumLicense:
'enterprise'`](https://github.com/elastic/kibana/pull/163031/files#diff-56de8b6234daf4e0e69efe680e5a4afc4f88d152243b773d90c3991fa9dabc19R28)
is configured on this privilege, when the license check isn't satisfied,
the privilege will be hidden (not disabled).
## Testing
Feature is available for `enterprise` licenses and when `All` privilege
is set, otherwise Assistant is hidden in Timeline, all `Chat` UI
elements are hidden, and the `cmd/ctrl + ;` shortcut is unavailable.
---
### On Prem Testing:
Create two roles, one for each `all`/`none` Security Elastic AI
Assistant privilege (via Dev Tools):
<details><summary>PUT /_security/role/assistant_all</summary>
<p>
``` ts
PUT /_security/role/assistant_all
{
"cluster": [
"all"
],
"indices": [
{
"names": [
"*"
],
"privileges": [
"all"
],
"field_security": {
"grant": [
"*"
],
"except": []
},
"allow_restricted_indices": false
}
],
"applications": [
{
"application": "kibana-.kibana",
"privileges": [
"feature_securitySolutionAssistant.minimal_all",
"feature_siem.all",
"feature_securitySolutionCases.all",
"feature_actions.all"
],
"resources": [
"*"
]
}
],
"run_as": [],
"metadata": {},
"transient_metadata": {
"enabled": true
}
}
```
</p>
</details>
<details><summary>PUT /_security/role/assistant_none</summary>
<p>
``` ts
PUT /_security/role/assistant_none
{
"cluster": [
"all"
],
"indices": [
{
"names": [
"*"
],
"privileges": [
"all"
],
"field_security": {
"grant": [
"*"
],
"except": []
},
"allow_restricted_indices": false
}
],
"applications": [
{
"application": "kibana-.kibana",
"privileges": [
"feature_siem.all",
"feature_securitySolutionCases.all",
"feature_actions.all"
],
"resources": [
"*"
]
}
],
"run_as": [],
"metadata": {},
"transient_metadata": {
"enabled": true
}
}
```
</p>
</details>
Create a new `assistant_user` (assigned both roles above), log in and
test assistant availability, then remove one role at a time testing
each:
<details><summary>POST /_security/user/assistant_user (ALL)</summary>
<p>
``` ts
POST /_security/user/assistant_user
{
"username": "assistant_user",
"password": "changeme",
"roles": [
"assistant_all",
"assistant_none"
],
"full_name": "Assistant User",
"email": "assistant-user@elastic.co",
"metadata": {},
"enabled": true
}
```
</p>
</details>
Test that assistant is available in UI via `Chat` buttons and shortcut
keys.
<details><summary>PUT /_security/user/assistant_user (NONE)</summary>
<p>
``` ts
PUT /_security/user/assistant_user
{
"username": "assistant_user",
"roles": [
"assistant_none"
],
"full_name": "Assistant User",
"email": "assistant-user@elastic.co",
"metadata": {},
"enabled": true
}
```
</p>
</details>
Test that assistant is **NOT** available in UI via `Chat` buttons or
shortcut keys.
---
### Serverless Testing:
To test with the Assistant available, set `productTypes` to `complete`
in `config/serverless.security.yml`
```
xpack.securitySolutionServerless.productTypes:
[
{ product_line: 'security', product_tier: 'complete' },
{ product_line: 'endpoint', product_tier: 'complete' },
]
```
otherwise to test without the Assistant, pick a different product type like `essentials`:
```
xpack.securitySolutionServerless.productTypes:
[
{ product_line: 'security', product_tier: 'essentials' },
{ product_line: 'endpoint', product_tier: 'essentials' },
]
```
Then start Serverless Kibana: `yarn serverless-security`
---
### Checklist
Delete any items that are not applicable to this PR.
- [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)
- [ ] [Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html) was added for features that require explanation or tutorials
- [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
## Summary
Fixes https://github.com/elastic/kibana/issues/149132
This PR adds a Kibana feature for the guided onboarding plugin for
better permissions handling. By default `kibana_admin` and `editor`
roles are granted access to guided onboarding. The role `viewer` on the
other hand doesn't have enough permissions to see or use guided
onboarding. For any roles that don't have the correct permissions,
guided onboarding is completely disabled, the same as it's disabled
on-prem.
When creating a new role, the feature "Setup guides" can be enabled or
disabled.
### How to test
1. Add `xpack.cloud.id: 'testID'` to `/config/kibana.dev.yml`
1. Start ES with `yarn es snapshot` and Kibana with `yarn start``
2. Login as elastic and create a test user with the role `viewer`
3. Clear everything from your browser's local storage
4. Login as the test user and check the following
- On the first visit, the "on-prem" welcome message is shown (not the
guided onboarding landing page)
- The url `/app/home#/getting_started` is unknown and redirects back to
the home page
- There is no button "Setup guides" in the header
- There is no link "Setup guides" in the help menu
### Checklist
- [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
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
From 8.8 `responseActionExecuteEnabled` is set to `true` by default
## Summary
Enables the `responseActionExecuteEnabled` feature flag by default for
`execute` response action.
### 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
## Summary
Resolves: https://github.com/elastic/kibana/issues/152270
Specs:
https://docs.google.com/document/u/1/d/1-QblF6P19W9o5-10Us3bfgN80GRfjSIhybHrvJS_ObA/edit
This PR implements the following:
- New maintenance window SO
- New maintenance window client in the alerting plugin (generates and
queries maintenance window events, and other CRUD functionality around
the SO)
- New maintenance window REST APIs
- Kibana privileges for reading/writing maintenance window
This PR does not include integration with task runner, a new PR will be
created to do that work.
## APIs:
```
Find all maintenance windows in current space
GET `${INTERNAL_BASE_ALERTING_API_PATH}/rules/maintenance_window/_find`
body: {}
```
```
Create maintenance window:
POST `${INTERNAL_BASE_ALERTING_API_PATH}/rules/maintenance_window`
body: {
title: string,
duration: number,
r_rule: RRule
}
```
```
Update maintenance window by ID:
POST `${INTERNAL_BASE_ALERTING_API_PATH}/rules/maintenance_window/{id}`,
body: {
title?: string,
duration?: number,
enabled?: boolean,
r_rule?: RRule,
}
```
```
Get maintenance window by ID:
GET `${INTERNAL_BASE_ALERTING_API_PATH}/rules/maintenance_window/{id}`,
```
```
Delete maintenance window by ID:
DELETE `${INTERNAL_BASE_ALERTING_API_PATH}/rules/maintenance_window/{id}`,
```
```
Archive maintenance window by ID:
POST `${INTERNAL_BASE_ALERTING_API_PATH}/rules/maintenance_window/{id}/_archive`,
body: {
archive: boolean
}
```
```
Finish maintenance window by ID:
POST `${INTERNAL_BASE_ALERTING_API_PATH}/rules/maintenance_window/{id}/_finish`,
```
## Maintenance window response schema:
```
{
id: string;
title: string;
enabled: boolean;
duration: number;
expirationDate: string;
events: DateRange[];
rRule: RRuleParams;
status: 'running' | 'upcoming' | 'finished' | 'archived';
startDate: string | null;
endDate: string | null;
createdBy: string | null;
updatedBy: string | null;
createdAt: string;
updatedAt: string;
}
```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Sets the Get File feature flag to true by default in preparation for the
release of the feature.
### 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: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Enable the RBAC feature flag for Endpoint management RBAC by default.
### 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
Introduce a default file kind for images in Kibana. This file kind will
be the download/upload target usable for all images across Kibana.
Consider the following:
A Kibana user wants to add a branding logo to their dashboard. They need
to create a new image or select from a set of existing images (i.e.,
images already uploaded). This set of images is the "default image" set.
The idea will be this set of images can be access across dashboards and
solutions. For example, the same user can access the branding image they
uploaded in Cases.
## How it works
* We added a new default file kind specifically for images, this is
registered from the files plugin
* In order to access these files over HTTP users will need the
`files:defaultImage` privilege
* This is a distinct privilege from the file management privilege and
allows users to access HTTP endpoints controlled by
`access:files:defaultImage` as well as the underlying `file` saved
object
* Consider a dashboard user that wants to add an image embeddable: they
will need access to `file` saved object as well as the endpoints for
creating/reading/deleting the default file kind. In order to get this
their role must grant the new "Shared images" privilege.
<img width="749" alt="Screenshot 2022-11-22 at 10 34 25"
src="https://user-images.githubusercontent.com/8155004/203295230-24a0be94-9c59-4a53-8757-336e9fc8f6c4.png">
## Summary
Files management UI that rounds out the files MVP. This is UI is
intended to be progressively enhanced and provides a way for system
administrators get some insight and manage the files created and stored
in Kibana.
## To reviewers
* This is UI for retrieval and deletion of files (the R+D of CRUD)
* Creating and deleting tags to be supported in a future version
* This UI is intended to form part of the broader content management
experience
* We use the `TableListView` component as far as possible
## How to test
1. Start Kibana with `yarn start --run-examples`
2. Go to the "Developer Examples" from the left nav menu
3. Go to the "Files example" plugin
4. Click the "Upload file" button, upload a few different image types
(PNG, JPG and WEBP)
5. Go to "Stack management" > "Files"
6. Behold your files in the management UI
7. (Bonus) check that the UI and API `GET /api/files/find`, `GET
/api/files/metrics` and `DELETE /api/files/blobs` are not accessible to
non-admin or appropriately privileged users (i.e., those with "Files
management" access).
## List of functionality
- [x] List all saved objects (scoped to admin)
- [x] Is able to bulk-delete files
- [x] Shows basic storage diagnostics
- [x] Is able to search and filter files
## Screenshots
<details>
<summary>screenshots</summary>
<img width="1545" alt="Screenshot 2022-11-08 at 13 56 54"
src="https://user-images.githubusercontent.com/8155004/200570783-cfefdbf3-c5ff-4ece-ba24-48a455fcca75.png">
<img width="910" alt="Screenshot 2022-11-10 at 12 52 35"
src="https://user-images.githubusercontent.com/8155004/201083812-bc9f25f5-b423-43a6-9229-5e2a4cdd943a.png">
<img width="451" alt="Screenshot 2022-11-10 at 12 37 07"
src="https://user-images.githubusercontent.com/8155004/201081039-832a1980-684c-4abb-bb05-0c7c6a849d4d.png">
<img width="959" alt="Screenshot 2022-11-08 at 13 57 15"
src="https://user-images.githubusercontent.com/8155004/200570797-f122cff5-7043-4e01-9b51-d5663c1b26d6.png">
<img width="500" alt="Screenshot 2022-11-08 at 13 57 38"
src="https://user-images.githubusercontent.com/8155004/200570801-35cdbd99-0256-4dee-9f78-2f6ad853305f.png">
</details>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
- Remove `file_operations_all` from list of sub-feature of SIEM
(security solution). This sub-feature [was recently placed behind an
experimental feature
flag](https://github.com/elastic/kibana/pull/145042), which is disabled
by default for 8.6.
- Un-skips tests
Fixes: #145134Fixes: #145135Fixes: #145136
## Summary
- Updates the `get-file` action response `outputs` to match latest from
endpoint
- Fix server size `doesFileHanveChunks()` and remove the `.keyword` from
the search field term (index mapping will be setup correctly for these
indexes)
- Updates the names of the File storage indexes
- Sets the `endpointRbacV1Enabled` FF to `true` (enables feature by
default)
- Uses Fleet exposed function utilities to retrieve the indexes for
File's metadata and data chunks
The following Fleet changes were also done
- Created common methods in fleet for retrieving the file metadata and
data indexes using an integration name (should protect us against index
names going forward and avoid having integrations in kibana keep
hard-coded values)
- Removed the .keyword from a few places in the file server service
(still need to test)
- Adjusted both the Fleet and the Security Solution code to use the new
methods for getting the integration specific index names (cc/
@juliaElastic )
* Augments /api/security/privileges with optional respectLicenseLevel parameter for use by the edit_role_page.
Implements fix for 125289 - Show sub-feature privileges when using the Basic license
* Changed EuiTooltip to EuiIconTip.
* Updated unit tests for feature table expanded row to include new property checks.
* Renamed property to improve readability and reduce confusion. Fixed state of switch checked in sub-feature customization.
* [CI] Auto-commit changed files from 'node scripts/eslint --no-cache --fix'
* Fixed privilege get API default for 'respectLicenseLevel'. Updated privilege unit tests.
* [CI] Auto-commit changed files from 'node scripts/precommit_hook.js --ref HEAD~1..HEAD --fix'
* Uodated test description to match property name.
* Updated privilege API integration tests to include new 'respectLicenseLevel' optional parameter.
* Replaced empty fragment with undefined.
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Thom Heymann <190132+thomheymann@users.noreply.github.com>
