From 19820d26fa238e67a536bc6cfe07edd9c18e36e7 Mon Sep 17 00:00:00 2001 From: Nastasha Solomon <79124755+nastasha-solomon@users.noreply.github.com> Date: Thu, 4 Dec 2025 11:49:32 -0500 Subject: [PATCH] [DOCS][ResponseOps][Alerting][9.1]: Add breaking change to CCS-based reporting to 9.1 Kibana release notes (#245183) ## Summary Contributes to http://github.com/elastic/docs-content-internal/issues/514 by documenting the breaking change to CCS-based reporting in the 9.1 Kibana release notes. Also took this opportunity to remove the `%` char from some breaking change descriptions (it was commenting out lines). ### Corresponding fixes - 8.19 reporting docs and Kibana release notes: https://github.com/elastic/kibana/pull/245182 - 9.1 reporting docs: https://github.com/elastic/docs-content/pull/4211 ## Previews - [9.1](https://docs-v3-preview.elastic.dev/elastic/kibana/pull/245183/release-notes/breaking-changes#kibana-9.1.0-breaking-changes) - see the second item in the section (cherry picked from commit a7a6130042f450e4ffcd560b8452bc9fdd7c43b4) --- docs/release-notes/breaking-changes.md | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/docs/release-notes/breaking-changes.md b/docs/release-notes/breaking-changes.md index 2458f4aee425a..26ded4159ff8d 100644 --- a/docs/release-notes/breaking-changes.md +++ b/docs/release-notes/breaking-changes.md @@ -39,7 +39,7 @@ If you are migrating from a version prior to version 9.0, you must first upgrade ## 9.2.0 [kibana-9.2.0-breaking-changes] $$$kibana-230067$$$ ::::{dropdown} Improved advanced settings management APIs privilege checks -% **Details**
Roles with explicit `read` access to advanced settings but `all` access to `SavedObjectManagement` can no longer update settings using the internal advanced settings API. This update enforces explicit privileges instead of relying on saved object security checks. +**Details**
Roles with explicit `read` access to advanced settings but `all` access to `SavedObjectManagement` can no longer update settings using the internal advanced settings API. This update enforces explicit privileges instead of relying on saved object security checks. View [#230067]({{kib-pull}}230067). :::: @@ -47,11 +47,22 @@ View [#230067]({{kib-pull}}230067). $$$kibana-213916$$$ ::::{dropdown} Change to variable syntax in {{esql}} queries -% **Details**
Fields and functions variables are now described with `??` in {{esql}} queries. For value variables, you can continue to use `?`. +**Details**
Fields and functions variables are now described with `??` in {{esql}} queries. For value variables, you can continue to use `?`. View [#213916]({{kib-pull}}213916). :::: +$$$kibana-216558$$$ +::::{dropdown} API keys are used for authenticating report generation requests + +**Details**
In 9.1.0, report generation requests are authenticated by API keys instead of session cookies. There are several key differences between the authentication methods. API keys capture your role privileges, whereas session cookie are based on your user credentials. API keys are also longer-lived, compared to session cookies, which have a shorter lifespan. + + +If you have a cross-cluster search environment and want to generate reports from remote clusters, you must have the appropriate cluster and index privileges on the remote cluster and local cluster. For example, if requests are authenticated with an API key, the API key requires certain privileges on the local cluster that contains the local index, in addition to the remote. For more information and examples, refer to [Configure roles and users for remote clusters](docs-content://deploy-manage/remote-clusters/remote-clusters-cert.md#remote-clusters-privileges-cert). + +View [#216558]({{kib-pull}}216558). +:::: + ## 9.0.0 [kibana-900-breaking-changes] $$$kibana-193792$$$ :::{dropdown} Access to {{kib}}'s internal APIs is blocked