github-mirrors/kibana
1
0
Fork 0
mirror of https://github.com/elastic/kibana.git synced 2025-04-24 17:59:23 -04:00
Code Issues Projects Releases Packages Wiki Activity
kibana/docs/upgrade-notes.asciidoc
Davis McPhee b53d3990a2
[Saved Queries] Rework saved query privileges (#202863) 
## 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>
2025-01-29 17:34:58 -04:00

362 lines
No EOL
18 KiB
Text
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

[[breaking-changes-summary]]
== Upgrade notes
////
USE THE FOLLOWING TEMPLATE to add entries to this document, from "[discrete]" to the last "====" included.
[discrete]
[[REPO-PR]]
.[FEATURE] TITLE TO DESCRIBE THE CHANGE. (VERSION)
[%collapsible]
====
*Details* +
ADD MORE DETAILS ON WHAT IS CHANGING AND A LINK TO THE PR INTRODUCING THE CHANGE
*Impact* +
ADD INFORMATION ABOUT WHAT THIS CHANGE WILL BREAK FOR USERS
*Action* +
ADD INSTRUCTIONS FOR USERS LOOKING TO UPGRADE. HOW CAN THEY WORK AROUND THIS?
====
1. Copy and edit the template in the right section of this file. Most recent entries should be at the top of the section, search for sections using the text "[float]".
2. Edit the anchor ID [[REPO-PR]] of the template with proper values.
3. Don't hardcode the link to the new entry. Instead, make it available through the doc link service files:
- {kib-repo}blob/{branch}/src/platform/packages/shared/kbn-doc-links/src/get_doc_links.ts
- {kib-repo}blob/{branch}/src/platform/packages/shared/kbn-doc-links/src/types.ts
The entry in the main links file should look like this:
id: `${KIBANA_DOCS}breaking-changes-summary.html#REPO-PR`
Where:
- `id` is the ID of your choice.
- `REPO-PR` is the anchor ID that you assigned to the entry in this upgrade document.
4. You can then call the link from any Kibana code. For example: `href: docLinks.links.upgradeAssistant.id`
Check https://docs.elastic.dev/docs/kibana-doc-links (internal) for more details about the Doc links service.
////
Before you upgrade, review the breaking changes and deprecations introduced since the version you are migrating from, then mitigate the impact.
If you are migrating from a version prior to version 9.0, you must first upgrade to the last 8.x version available.
For Elastic Security solution release information, refer to {security-guide}/release-notes.html[_Elastic Security Solution Release Notes_].
[float]
=== Breaking changes
[discrete]
[[breaking-207091]]
.Removed legacy security rules bulk endpoints (9.0.0)
[%collapsible]
====
*Details* +
--
* `POST /api/detection_engine/rules/_bulk_create` has been replaced by `POST /api/detection_engine/rules/_import`
* `PUT /api/detection_engine/rules/_bulk_update` has been replaced by `POST /api/detection_engine/rules/_bulk_action`
* `PATCH /api/detection_engine/rules/_bulk_update has been replaced by `POST /api/detection_engine/rules/_bulk_action`
* `DELETE /api/detection_engine/rules/_bulk_delete` has been replaced by `POST /api/detection_engine/rules/_bulk_action`
* `POST api/detection_engine/rules/_bulk_delete` has been replaced by `POST /api/detection_engine/rules/_bulk_action`
--
These changes were introduced in {kibana-pull}197422[#197422].
*Impact* +
Deprecated endpoints will fail with a 404 status code starting from version 9.0.0
*Action* +
--
Update your implementations to use the new endpoints:
* **For bulk creation of rules:**
- Use `POST /api/detection_engine/rules/_import` (link:{api-kibana}/operation/operation-importrules[API documentation]) to create multiple rules along with their associated entities (for example, exceptions and action connectors).
- Alternatively, create rules individually using `POST /api/detection_engine/rules` (link:{api-kibana}/operation/operation-createrule[API documentation]).
* **For bulk updates of rules:**
- Use `POST /api/detection_engine/rules/_bulk_action` (link:{api-kibana}/operation/operation-performrulesbulkaction[API documentation]) to update fields in multiple rules simultaneously.
- Alternatively, update rules individually using `PUT /api/detection_engine/rules` (link:{api-kibana}/operation/operation-updaterule[API documentation]).
* **For bulk deletion of rules:**
- Use `POST /api/detection_engine/rules/_bulk_action` (link:{api-kibana}/operation/operation-performrulesbulkaction[API documentation]) to delete multiple rules by IDs or query.
- Alternatively, delete rules individually using `DELETE /api/detection_engine/rules` (link:{api-kibana}/operation/operation-deleterule[API documentation]).
--
====
[discrete]
[[breaking-199598]]
.Remove deprecated endpoint management endpoints (9.0.0)
[%collapsible]
====
*Details* +
--
* `POST /api/endpoint/isolate` has been replaced by `POST /api/endpoint/action/isolate`
* `POST /api/endpoint/unisolate` has been replaced by `POST /api/endpoint/action/unisolate`
* `GET /api/endpoint/policy/summaries` has been deprecated without replacement. Will be removed in v9.0.0
* `POST /api/endpoint/suggestions/{suggestion_type}` has been deprecated without replacement. Will be removed in v9.0.0
* `GET /api/endpoint/action_log/{agent_id}` has been deprecated without replacement. Will be removed in v9.0.0
* `GET /api/endpoint/metadata/transforms` has been deprecated without replacement. Will be removed in v9.0.0
--
*Impact* +
Deprecated endpoints will fail with a 404 status code starting from version 9.0.0
*Action* +
--
* Remove references to `GET /api/endpoint/policy/summaries` endpoint.
* Remove references to `POST /api/endpoint/suggestions/{suggestion_type}` endpoint.
* Remove references to `GET /api/endpoint/action_log/{agent_id}` endpoint.
* Remove references to `GET /api/endpoint/metadata/transforms` endpoint.
* Replace references to deprecated endpoints with the replacements listed in the breaking change details.
--
====
[discrete]
[[breaking-201550]]
.Removed legacy alerting endpoints (9.0.0)
[%collapsible]
====
*Details* +
--
* `POST /api/alerts/alert/{id?}` has been replaced by `POST /api/alerting/rule/{id?}`
* `GET /api/alerts/alert/{id}` has been replaced by `GET /api/alerting/rule/{id}`
* `PUT /api/alerts/alert/{id}` has been replaced by `PUT /api/alerting/rule/rule/{id}`
* `DELETE: /api/alerts/alert/{id}` has been replaced by `DELETE /api/alerting/rule/{id}`
* `POST /api/alerts/alert/{id}/_disable` has been replaced by `POST /api/alerting/rule/{id}/_disable`
* `POST /api/alerts/alert/{id}/_enable` has been replaced by `POST /api/alerting/rule/{id}/_enable`
* `GET /api/alerts/_find` has been replaced by `GET /api/alerting/rules/_find`
* `GET /api/alerts/_health` has been replaced by `GET /api/alerting/rule/_health`
* `GET /api/alerts/list_alert_types` has been replaced by `GET /api/alerting/rule_types`
* `POST /api/alerts/alert/{alert_id}/alert_instance/{alert_instance_id}/_mute` has been replaced by `POST /api/alerting/rule/{rule_id}/alert/{alert_id}/_mute`
* `POST /api/alerts/alert/{alert_id}/alert_instance/{alert_instance_id}/_unmute` has been replaced by `POST /api/alerting/rule/{rule_id}/alert/{alert_id}/_unmute`
* `POST /api/alerts/alert/{id}/_mute_all` has been replaced by `POST /api/alerting/rule/{id}/_mute_all`
* `POST /api/alerts/alert/{id}/_unmute_all` has been replaced by `POST /api/alerting/rule/{id}/_unmute_all`
* `POST /api/alerts/alert/{id}/_update_api_key` has been replaced by `POST /api/alerting/rule/{id}/_update_api_key`
* `GET /api/alerts/{id}/_instance_summary` has been deprecated without replacement. Will be removed in v9.0.0
* `GET /api/alerts/{id}/state` has been deprecated without replacement. Will be removed in v9.0.0
--
*Impact* +
Deprecated endpoints will fail with a 404 status code starting from version 9.0.0
*Action* +
Remove references to `GET /api/alerts/{id}/_instance_summary` endpoint.
Remove references to `GET /api/alerts/{id}/state` endpoint.
Replace references to endpoints listed as deprecated by it's replacement. See `Details` section.
The updated APIs can be found here https://www.elastic.co/docs/api/doc/kibana/v8/group/endpoint-alerting
====
[[breaking-201004]]
.Removed legacy cases endpoints (9.0.0)
[%collapsible]
====
*Details* +
--
* `GET /api/cases/status` has been deprecated with no replacement. Deleted in v9.0.0
* `GET /api/cases/{case_id}/comments` has been replaced by `GET /api/cases/{case_id}/comments/_find` released in v7.13
* `GET /api/cases/<case_id>/user_actions` has been replaced by `GET /api/cases/<case_id>/user_actions/_find` released in v8.7
* `includeComments` parameter in `GET /api/cases/{case_id}` has been deprecated. Use `GET /api/cases/{case_id}/comments/_find` instead, released in v7.13
--
*Impact* +
Deprecated endpoints will fail with a 404 status code starting from version 9.0.0
*Action* +
Remove references to `GET /api/cases/status` endpoint.
Replace references to deprecated endpoints with the replacements listed in the breaking change details.
====
[[breaking-199656]]
.Removed all security v1 endpoints (9.0.0)
[%collapsible]
====
*Details* +
All `v1` Kibana security HTTP endpoints have been removed.
`GET /api/security/v1/logout` has been replaced by `GET /api/security/logout`
`GET /api/security/v1/oidc/implicit` has been replaced by `GET /api/security/oidc/implicit`
`GET /api/security/v1/oidc` has been replaced by GET `/api/security/oidc/callback`
`POST /api/security/v1/oidc` has been replaced by POST `/api/security/oidc/initiate_login`
`POST /api/security/v1/saml` has been replaced by POST `/api/security/saml/callback`
`GET /api/security/v1/me` has been removed with no replacement.
For more information, refer to {kibana-pull}199656[#199656].
*Impact* +
Any HTTP API calls to the `v1` Kibana security endpoints will fail with a 404 status code starting from version 9.0.0.
Third party OIDC and SAML identity providers configured with `v1` endpoints will no longer work.
*Action* +
Update any OIDC and SAML identity providers to reference the corresponding replacement endpoint listed above.
Remove references to the `/api/security/v1/me` endpoint from any automations, applications, tooling, and scripts.
====
[discrete]
[[breaking-193792]]
.Access to all internal APIs is blocked (9.0.0)
[%collapsible]
====
*Details* +
Access to internal Kibana HTTP APIs is restricted from version 9.0.0. This is to ensure
that HTTP API integrations with Kibana avoid unexpected breaking changes.
Refer to {kibana-pull}193792[#193792].
*Impact* +
Any HTTP API calls to internal Kibana endpoints will fail with a 400 status code starting
from version 9.0.0.
*Action* +
**Do not integrate with internal HTTP APIs**. They may change or be removed without notice,
and lead to unexpected behaviors. If you would like some capability to be exposed over an
HTTP API, https://github.com/elastic/kibana/issues/new/choose[create an issue].
We would love to discuss your use case.
====
[discrete]
[[breaking-201810]]
.Remove original user and host risk scoring and all associated UIs (9.0.0)
[%collapsible]
====
*Details* +
--
The original host and risk score modules have been superseded since v8.10.0 by the Risk Engine.
In 9.0.0 these modules are no longer supported, the scores no longer display in the UI
and all UI controls associated with managing or upgrading the legacy modules have been removed.
--
*Impact* +
As well as the legacy risk scores not being shown in the UI, alerts no longer have the legacy risk score added to them in the `<host|user>.risk.calculated_level`
and `<host|user>.risk.calculated_score_norm` fields.
The legacy risk scores are stored in the `ml_host_risk_score_<space_id>` and `ml_user_risk_score_<space_id>`
indices, these indices will not be deleted if the user chooses not to upgrade.
Legacy risk scores are generated by the following transforms:
- `ml_hostriskscore_pivot_transform_<space_id>`
- `ml_hostriskscore_latest_transform_<space_id>`
- `ml_userriskscore_pivot_transform_<space_id>`
- `ml_userriskscore_latest_transform_<space_id>`
If a user does not upgrade to use the Risk Engine, these transforms will continue to run in 9.0.0, but it will be up to the user to manage them.
*Action* +
Upgrade to use the Risk Engine in all spaces which use the legacy risk scoring modules:
- In the main menu, go to *Security > Manage > Entity Risk Score*.
- If the original user and host risk score modules are enabled, you'll see a button to "Start update". Click the button, and follow the instructions.
====
[discrete]
[[breaking-200834]]
.Reporting uses Kibana feature privileges only to control access to reporting features
[%collapsible]
====
*Details* +
--
In 8.x, the default access control model was based on a built-in role called `reporting_user`, which granted access to reporting features. Since 7.13, the preferred model for controlling access to reporting features has been Kibana feature privileges, enabled by setting `xpack.reporting.roles.enabled: false` in `kibana.yml`.
In 9.0.0, the `xpack.reporting.roles.*` settings will be ignored.
--
*Impact* +
The built-in `reporting_user` role is no longer deprecated and provides access to reporting features using Kibana feature privileges. This means that users that do not have privileges to use reporting will not see reporting features in the Kibana UI.
*Action* +
Use Kibana feature privileges to control access to reporting features. For more information, see {kibana-pull}200834[#200834].
- The `reporting_user` role is still supported, but gives full access to all reporting features. We recommend creating custom roles with minimal privileges in **Stack Management > Roles**.
- The `xpack.reporting.roles.allow` setting is no longer supported. If you have a `xpack.reporting.roles.allow` value in your `kibana.yml`, you should remove this setting and assign privileges to reporting features using Kibana feature privileges.
====
[discrete]
[[breaking-202863]]
.Saved query privileges have been reworked (9.0.0)
[%collapsible]
====
*Details* +
Saved query privileges have been reworked to rely solely on a single global `savedQueryManagement` privilege, and eliminate app-specific overrides (e.g. implicit access with `all` privilege for Discover, Dashboard, Maps, and Visualize apps). This change simplifies the security model and ensures consistency in the saved query management UI across Kibana, but results in different handling of saved query privileges for new user roles, and minor breaking changes to the existing management UX.
For more information, refer to {kibana-pull}202863[#202863].
*Impact* +
The `savedQueryManagement` feature privilege now globally controls access to saved query management for all new user roles. Regardless of privileges for Discover, Dashboard, Maps, or Visualize, new user roles 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.
*Action* +
Existing user roles that were previously implicitly granted access to saved queries through the dashboard, discover, visualize, or maps feature privileges will retain that access to prevent breaking changes. While no action is required for existing roles, it’s still advisable to audit relevant roles and re-save them to migrate to the latest privileges model. For new roles, ensure that the savedQueryManagement privilege is set as needed.
====
[float]
=== Deprecation notices
The following functionality is deprecated and will be removed at a future date. Deprecated functionality
does not have an immediate impact on your application, but we strongly recommend you make the necessary
updates to avoid use of deprecated features.
Use the **Kibana Upgrade Assistant** to prepare for your upgrade to the next version of the Elastic Stack.
The assistant identifies deprecated settings in your configuration and guides you through the process of
resolving issues if any deprecated features are enabled.
To access the assistant, go to **Stack Management** > **Upgrade Assistant**.
[discrete]
[[deprecation-202250]]
.Scripted field creation has been disabled in the Data Views management page (9.0.0)
[%collapsible]
====
*Details* +
The ability to create new scripted fields has been removed from the *Data Views* management page in 9.0. Existing scripted fields can still be edited or deleted, and the creation UI can be accessed by navigating directly to `/app/management/kibana/dataViews/dataView/{dataViewId}/create-field`, but we recommend migrating to runtime fields or ES|QL queries instead to prepare for removal.
For more information, refer to {kibana-pull}202250[#202250].
*Impact* +
It will no longer be possible to create new scripted fields directly from the *Data Views* management page.
*Action* +
Migrate to runtime fields or ES|QL instead of creating new scripted fields. Existing scripted fields can still be edited or deleted.
====
[discrete]
[[known-issue-204384]]
.Now HTTP/2 is the default protocol when TLS is enabled and a deprecation warning appears if HTTP/2 is not enabled or TLS is not configured (9.0.0)
[%collapsible]
====
*Details* +
Starting from version 9.0.0, HTTP/2 is the default protocol when TLS is enabled. This ensures improved performance and security. However, if HTTP/2 is not enabled or TLS is not configured, a deprecation warning will be added.
For more information, refer to {kibana-pull}204384[#204384].
*Impact* +
Systems that have TLS enabled but don't specify a protocol will start using HTTP/2 in 9.0.0.
Systems that use HTTP/1 or don't have TLS configured will get a deprecation warning.
*Action* +
Verify that TLS is properly configured by enabling it and providing valid certificates in the settings. Test your system to ensure that connections are established securely over HTTP/2.
If your Kibana server is hosted behind a load balancer or reverse proxy we recommend testing your deployment configuration before upgrading to 9.0.
====
[discrete]
[[known-issue-206998]]
.Search sessions disabled by default (9.0.0)
[%collapsible]
====
*Details* +
Starting from version 9.0.0, search sessions are disabled by default. To view, manage, and restore search sessions, the feature needs to be explicitly re-enabled.
*Impact* +
Search sessions will be disabled unless they are explicitly enabled in config.yml.
*Action* +
If you would like to continue using, managing, and restoring search sessions in 9.0, you'll need to re-enable the feature in your kibana.yml configuration file. If not, no action is necessary.
To re-enable search sessions, add the following in your config.yml:
```
data.search.sessions.enabled: true
```
====
Reference in a new issue View git blame Copy permalink