mirror of
https://github.com/elastic/kibana.git
synced 2025-04-24 01:38:56 -04:00
# Backport This will backport the following commits from `main` to `9.0`: - [[Docs] Simplify link to PRs in breaking changes and deprecation notices (#214444)](https://github.com/elastic/kibana/pull/214444) <!--- Backport version: 9.6.6 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport) <!--BACKPORT [{"author":{"name":"florent-leborgne","email":"florent.leborgne@elastic.co"},"sourceCommit":{"committedDate":"2025-03-13T17:50:58Z","message":"[Docs] Simplify link to PRs in breaking changes and deprecation notices (#214444)\n\nThis PR simplifies the wording in breaking changes and deprecations docs\nto feel less redundant, and re-adds a proper template for adding new\nentries.","sha":"2e80cd19f5dee2e08d96f072a001fd7ff8ac4d08","branchLabelMapping":{"^v9.1.0$":"main","^v8.19.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Team:Docs","release_note:skip","v9.0.0","docs","backport:version","v9.1.0"],"title":"[Docs] Simplify link to PRs in breaking changes and deprecation notices","number":214444,"url":"https://github.com/elastic/kibana/pull/214444","mergeCommit":{"message":"[Docs] Simplify link to PRs in breaking changes and deprecation notices (#214444)\n\nThis PR simplifies the wording in breaking changes and deprecations docs\nto feel less redundant, and re-adds a proper template for adding new\nentries.","sha":"2e80cd19f5dee2e08d96f072a001fd7ff8ac4d08"}},"sourceBranch":"main","suggestedTargetBranches":["9.0"],"targetPullRequestStates":[{"branch":"9.0","label":"v9.0.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"main","label":"v9.1.0","branchLabelMappingKey":"^v9.1.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/214444","number":214444,"mergeCommit":{"message":"[Docs] Simplify link to PRs in breaking changes and deprecation notices (#214444)\n\nThis PR simplifies the wording in breaking changes and deprecations docs\nto feel less redundant, and re-adds a proper template for adding new\nentries.","sha":"2e80cd19f5dee2e08d96f072a001fd7ff8ac4d08"}}]}] BACKPORT--> Co-authored-by: florent-leborgne <florent.leborgne@elastic.co>
This commit is contained in:
Kibana Machine
GitHub
parent
5d103888fe
commit
63331c0e8c
3 changed files with 55 additions and 14 deletions
|
|
@ -12,12 +12,30 @@ If you are migrating from a version prior to version 9.0, you must first upgrade
|
|||
% ## Next version [kibana-nextversion-breaking-changes]
|
||||
% **Release date:** Month day, year
|
||||
|
||||
% Use the following template to add entries to this document.
|
||||
|
||||
% TEMPLATE START
|
||||
% $$$kibana-PR_NUMBER$$$
|
||||
% ::::{dropdown} Title of breaking change
|
||||
% Description of the breaking change.
|
||||
% For more information, check [PR #](PR link).
|
||||
% **Impact**<br> Impact of the breaking change.
|
||||
% **Action**<br> Steps for mitigating deprecation impact.
|
||||
% **Action**<br> Steps for mitigating impact.
|
||||
% View [PR #](PR link).
|
||||
% ::::
|
||||
% TEMPLATE END
|
||||
|
||||
% 1. Copy and edit the template in the right area section of this file. Most recent entries should be at the top of the section.
|
||||
% 2. Edit the anchor ID ($$$kibana-PR_NUMBER$$$) of the template with the correct PR number to give the entry a unique URL.
|
||||
% 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.html#kibana-PR_NUMBER`
|
||||
%
|
||||
% 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.
|
||||
|
||||
## 9.0.0 [kibana-900-breaking-changes]
|
||||
**Release date:** March 25, 2025
|
||||
|
|
@ -61,19 +79,21 @@ 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, check [#199656](https://github.com/elastic/kibana/pull/199656).
|
||||
|
||||
**Impact**<br> 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**<br> 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.
|
||||
|
||||
View [#199656](https://github.com/elastic/kibana/pull/199656).
|
||||
::::
|
||||
|
||||
:::{dropdown} Access to all internal APIs is blocked
|
||||
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 [#193792](https://github.com/elastic/kibana/pull/193792).
|
||||
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.
|
||||
|
||||
**Impact**<br> Any HTTP API calls to internal Kibana endpoints will fail with a 400 status code starting from version 9.0.0.
|
||||
|
||||
**Action**<br> **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, [create an issue](https://github.com/elastic/kibana/issues/new/choose). We would love to discuss your use case.
|
||||
|
||||
View [#193792](https://github.com/elastic/kibana/pull/193792).
|
||||
::::
|
||||
|
||||
:::{dropdown} Remove original user and host risk scoring and all associated UIs
|
||||
|
|
@ -107,16 +127,20 @@ In 9.0.0, the `xpack.reporting.roles.*` settings will be ignored.
|
|||
|
||||
**Impact**<br> 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**<br> Use Kibana feature privileges to control access to reporting features. For more information, see [#200834](https://github.com/elastic/kibana/pull/200834).
|
||||
**Action**<br> Use Kibana feature privileges to control access to reporting features.
|
||||
|
||||
* 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.
|
||||
|
||||
View [#200834](https://github.com/elastic/kibana/pull/200834).
|
||||
::::
|
||||
|
||||
:::{dropdown} Saved query privileges have been reworked
|
||||
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, check [#202863](https://github.com/elastic/kibana/pull/202863).
|
||||
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.
|
||||
|
||||
**Impact**<br> 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**<br> 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.
|
||||
|
||||
View [#202863](https://github.com/elastic/kibana/pull/202863).
|
||||
::::
|
||||
|
|
@ -10,12 +10,30 @@ To learn how to upgrade, check out <uprade docs>.
|
|||
% ## Next version [kibana-versionnext-deprecations]
|
||||
% **Release date:** Month day, year
|
||||
|
||||
% Use the following template to add entries to this document.
|
||||
|
||||
% TEMPLATE START
|
||||
% $$$kibana-PR_NUMBER$$$
|
||||
% ::::{dropdown} Deprecation title
|
||||
% Description of the deprecation.
|
||||
% For more information, check [PR #](PR link).
|
||||
% **Impact**<br> Impact of deprecation.
|
||||
% **Action**<br> Steps for mitigating deprecation impact.
|
||||
% **Impact**<br> Impact of the deprecation.
|
||||
% **Action**<br> Steps for mitigating impact.
|
||||
% View [PR #](PR link).
|
||||
% ::::
|
||||
% TEMPLATE END
|
||||
|
||||
% 1. Copy and edit the template in the right area section of this file. Most recent entries should be at the top of the section.
|
||||
% 2. Edit the anchor ID ($$$kibana-PR_NUMBER$$$) of the template with the correct PR number to give the entry a unique URL.
|
||||
% 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}deprecations.html#kibana-PR_NUMBER`
|
||||
%
|
||||
% 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.
|
||||
|
||||
## 9.0.0 [kibana-900-deprecations]
|
||||
**Release date:** March 25, 2025
|
||||
|
|
@ -23,9 +41,9 @@ To learn how to upgrade, check out <uprade docs>.
|
|||
::::{dropdown} Scripted field creation has been disabled in the Data Views management page
|
||||
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, check [#202250](https://github.com/elastic/kibana/pull/202250).
|
||||
|
||||
**Impact**<br> It will no longer be possible to create new scripted fields directly from the **Data Views** management page.
|
||||
|
||||
**Action**<br> Migrate to runtime fields or ES|QL instead of creating new scripted fields. Existing scripted fields can still be edited or deleted.
|
||||
|
||||
View [#202250](https://github.com/elastic/kibana/pull/202250).
|
||||
::::
|
||||
|
|
@ -11,14 +11,13 @@ navigation_title: "Kibana"
|
|||
|
||||
**Details**<br> 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 [#204384](https://github.com/elastic/kibana/pull/204384).
|
||||
|
||||
**Impact**<br> 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**<br> 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.
|
||||
|
||||
View [#204384](https://github.com/elastic/kibana/pull/204384).
|
||||
::::
|
||||
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue