mirror of
https://github.com/elastic/kibana.git
synced 2025-04-22 08:49:27 -04:00
b53d3990a2
## 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> |
||
|---|---|---|
| .. | ||
| kbn-ambient-common-types | ||
| kbn-ambient-ftr-types | ||
| kbn-ambient-storybook-types | ||
| kbn-ambient-ui-types | ||
| kbn-apm-synthtrace | ||
| kbn-apm-synthtrace-client | ||
| kbn-axe-config | ||
| kbn-babel-preset | ||
| kbn-babel-register | ||
| kbn-babel-transform | ||
| kbn-bazel-runner | ||
| kbn-capture-oas-snapshot-cli | ||
| kbn-check-mappings-update-cli | ||
| kbn-check-prod-native-modules-cli | ||
| kbn-ci-stats-core | ||
| kbn-ci-stats-performance-metrics | ||
| kbn-ci-stats-reporter | ||
| kbn-ci-stats-shipper-cli | ||
| kbn-cli-dev-mode | ||
| kbn-code-owners | ||
| kbn-cypress-config | ||
| kbn-dependency-ownership | ||
| kbn-dependency-usage | ||
| kbn-dev-cli-errors | ||
| kbn-dev-cli-runner | ||
| kbn-dev-proc-runner | ||
| kbn-dev-utils | ||
| kbn-docs-utils | ||
| kbn-es | ||
| kbn-es-archiver | ||
| kbn-eslint-config | ||
| kbn-eslint-plugin-css | ||
| kbn-eslint-plugin-disable | ||
| kbn-eslint-plugin-eslint | ||
| kbn-eslint-plugin-i18n | ||
| kbn-eslint-plugin-imports | ||
| kbn-eslint-plugin-telemetry | ||
| kbn-expect | ||
| kbn-failed-test-reporter-cli | ||
| kbn-find-used-node-modules | ||
| kbn-ftr-common-functional-services | ||
| kbn-ftr-common-functional-ui-services | ||
| kbn-ftr-screenshot-filename | ||
| kbn-gen-ai-functional-testing | ||
| kbn-generate | ||
| kbn-generate-console-definitions | ||
| kbn-get-repo-files | ||
| kbn-import-locator | ||
| kbn-import-resolver | ||
| kbn-io-ts-utils | ||
| kbn-jest-serializers | ||
| kbn-journeys | ||
| kbn-json-ast | ||
| kbn-kibana-manifest-schema | ||
| kbn-lint-packages-cli | ||
| kbn-lint-ts-projects-cli | ||
| kbn-managed-vscode-config | ||
| kbn-managed-vscode-config-cli | ||
| kbn-management | ||
| kbn-manifest | ||
| kbn-mock-idp-plugin | ||
| kbn-mock-idp-utils | ||
| kbn-openapi-bundler | ||
| kbn-openapi-generator | ||
| kbn-optimizer | ||
| kbn-optimizer-webpack-helpers | ||
| kbn-peggy | ||
| kbn-peggy-loader | ||
| kbn-performance-testing-dataset-extractor | ||
| kbn-picomatcher | ||
| kbn-plugin-check | ||
| kbn-plugin-generator | ||
| kbn-plugin-helpers | ||
| kbn-relocate | ||
| kbn-repo-file-maps | ||
| kbn-repo-linter | ||
| kbn-repo-path | ||
| kbn-repo-source-classifier | ||
| kbn-repo-source-classifier-cli | ||
| kbn-scout | ||
| kbn-scout-info | ||
| kbn-scout-reporting | ||
| kbn-set-map | ||
| kbn-some-dev-log | ||
| kbn-sort-package-json | ||
| kbn-stdio-dev-helpers | ||
| kbn-storybook | ||
| kbn-styled-components-mapping-cli | ||
| kbn-telemetry-tools | ||
| kbn-test | ||
| kbn-test-eui-helpers | ||
| kbn-test-jest-helpers | ||
| kbn-test-subj-selector | ||
| kbn-tooling-log | ||
| kbn-ts-projects | ||
| kbn-ts-type-check-cli | ||
| kbn-validate-next-docs-cli | ||
| kbn-web-worker-stub | ||
| kbn-whereis-pkg-cli | ||
| kbn-yarn-lock-validator | ||
| serverless/storybook/config | ||
| README.md | ||
Kibana-related packages
This folder contains packages that are intended for use in Kibana and Kibana plugins.
tl;dr:
- Don't publish to npm registry
- Always use the
@kbnnamespace - Always set
"private": trueinpackage.json
Using these packages
We no longer publish these packages to the npm registry. Now, instead of specifying a version when including these packages, we rely on yarn workspaces, which sets up a symlink to the package.
For example if you want to use the @kbn/i18n package in Kibana itself, you
can specify the dependency like this:
"@kbn/i18n": "1.0.0"
However, if you want to use this from a Kibana plugin, you need to use a link:
dependency and account for the relative location of the Kibana repo, so it would
instead be:
"@kbn/i18n": "link:../../kibana/src/platform/packages/shared/kbn-i18n"
then run yarn kbn bootstrap from the plugin directory.
Creating a new package
Run the following command from the root of the Kibana repo:
node scripts/generate package @kbn/<PACKAGE_NAME> --web --owner @elastic/<TEAM_NAME>
Unit tests for a package
Currently there is only one tool being used in order to test packages which is Jest. Below we will explain how it should be done.
Jest
A package should follow the pattern of having .test.js files as siblings of the source code files, and these run by Jest.
A package using the .test.js naming convention will have those tests automatically picked up by Jest and run by the unit test runner, currently mapped to the Kibana test script in the root package.json.
yarn testruns all unit tests.yarn jestruns all Jest tests in Kibana.
In order for the plugin or package to use Jest, a jest.config.js file must be present in it's root. However, there are safeguards for this in CI should a test file be added without a corresponding config file.
Each package can also specify its own test script in the package's package.json, for cases where you'd prefer to run the tests from the local package directory.