mirror of
https://github.com/elastic/kibana.git
synced 2025-04-24 17:59:23 -04:00
## 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>
261 lines
11 KiB
Text
261 lines
11 KiB
Text
[role="xpack"]
|
|
[[secure-reporting]]
|
|
== Configure reporting in {kib}
|
|
|
|
++++
|
|
<titleabbrev>Configure reporting</titleabbrev>
|
|
++++
|
|
|
|
[NOTE]
|
|
============
|
|
Kibana PNG/PDF Reporting uses a custom binary of headless Chromium, and support comes with special caveats:
|
|
|
|
* The functionality requires special OS dependencies which may not be available for all distributions and configurations of Linux.
|
|
* It is subject to system resource configurations such as the limited number of file descriptors, allowed processes, and types of processes.
|
|
* Linux versions that are in end-of-life phase are not supported.
|
|
* Linux systems with SELinux or fapolicyd are not supported.
|
|
|
|
Before upgrading Kibana in a production environment, we encourage you to test your screenshotting use cases in a pre-production environment
|
|
to make sure your hosts support our latest build of Chromium. For the most reliable configuration of PDF/PNG {report-features}, consider
|
|
installing {kib} using <<docker, Docker>>, or using <<set-up-on-cloud, Elastic Cloud>>.
|
|
============
|
|
|
|
For security, you grant users access to the {report-features} and secure the reporting endpoints
|
|
with TLS/SSL encryption. Additionally, you can install graphical packages into the operating system
|
|
to enable the {kib} server to have screenshotting capabilities.
|
|
|
|
* <<grant-user-access>>
|
|
* <<reporting-roles-user-api>>
|
|
* <<grant-user-access-basic>>
|
|
* <<grant-user-access-external-provider>>
|
|
* <<securing-reporting>>
|
|
* <<install-reporting-packages>>
|
|
* <<set-reporting-server-host>>
|
|
* <<reporting-elasticsearch-configuration>>
|
|
|
|
[float]
|
|
[[grant-user-access]]
|
|
=== Grant users access to reporting
|
|
When security is enabled, you grant users access to {report-features} with <<kibana-privileges, {kib} application privileges>>, which allow you to create custom roles that control the spaces and applications where users generate reports.
|
|
|
|
. Create the reporting role.
|
|
|
|
.. Go to the *Roles* management page using the navigation menu or the
|
|
<<kibana-navigation-search,global search field>>.
|
|
|
|
.. Click *Create role*.
|
|
|
|
. Specify the role settings.
|
|
|
|
.. Enter the *Role name*. For example, `custom_reporting_user`.
|
|
|
|
.. Specify the *Indices* and *Privileges*.
|
|
+
|
|
Access to data is an index-level privilege. For each index that contains the data you want to include in reports, add a line, then give each index `read` and `view_index_metadata` privileges.
|
|
+
|
|
NOTE: If you use index aliases, you must also grant `read` and `view_index_metadata` privileges to underlying indices to generate CSV reports.
|
|
+
|
|
For more information, refer to {ref}/security-privileges.html[Security privileges].
|
|
|
|
. Add the {kib} privileges.
|
|
|
|
.. Click *Add Kibana privilege*.
|
|
|
|
.. Select one or more *Spaces*.
|
|
|
|
.. Click *Customize*, then click *Analytics*.
|
|
|
|
.. For each application, select *All*, or to customize the privileges, select *Read* and *Customize sub-feature privileges*.
|
|
+
|
|
NOTE: If you have a Basic license, sub-feature privileges are unavailable. For details, check out <<grant-user-access-basic>>.
|
|
[role="screenshot"]
|
|
image::user/reporting/images/kibana-privileges-with-reporting.png["Kibana privileges with Reporting options, Gold or higher license"]
|
|
+
|
|
NOTE: If the *Reporting* options for application features are unavailable, and the cluster license is higher than Basic, contact your administrator.
|
|
|
|
.. Click *Add {kib} privilege*.
|
|
|
|
. Click *Create role*.
|
|
|
|
. Assign the reporting role to a user.
|
|
|
|
.. Go to the *Users* management page using the navigation menu or the
|
|
<<kibana-navigation-search,global search field>>.
|
|
|
|
.. Select the user you want to assign the reporting role to.
|
|
|
|
.. From the *Roles* dropdown, select *custom_reporting_user*.
|
|
|
|
.. Click *Update user*.
|
|
|
|
Granting the privilege to generate reports also grants the user the privilege to view their reports in *Stack Management > Reporting*. Users can only access their own reports.
|
|
|
|
[float]
|
|
[[reporting-roles-user-api]]
|
|
==== Grant access with the role API
|
|
With <<grant-user-access,{kib} application privileges>>, you can use the {api-kibana}/group/endpoint-roles[role APIs] to grant access to the {report-features}, using *All* privileges, or sub-feature privileges.
|
|
|
|
NOTE: This API request needs to be run against the <<api,Kibana API endpoint>>.
|
|
|
|
[source, sh]
|
|
---------------------------------------------------------------
|
|
PUT <kibana host>:<port>/api/security/role/custom_reporting_user
|
|
{
|
|
"elasticsearch": {
|
|
"cluster": [],
|
|
"indices": [],
|
|
"run_as": []
|
|
},
|
|
"kibana": [{
|
|
"spaces": ["*"],
|
|
"base": [],
|
|
"feature": {
|
|
"dashboard_v2": ["generate_report", <1>
|
|
"download_csv_report"], <2>
|
|
"discover_v2": ["generate_report"], <3>
|
|
"canvas": ["generate_report"], <4>
|
|
"visualize_v2": ["generate_report"] <5>
|
|
}
|
|
}]
|
|
}
|
|
---------------------------------------------------------------
|
|
// CONSOLE
|
|
|
|
<1> Grants access to generate PNG and PDF reports in *Dashboard*.
|
|
<2> Grants access to generate CSV reports from saved Discover session panels in *Dashboard*.
|
|
<3> Grants access to generate CSV reports from saved Discover sessions in *Discover*.
|
|
<4> Grants access to generate PDF reports in *Canvas*.
|
|
<5> Grants access to generate PNG and PDF reports in *Visualize Library*.
|
|
|
|
[float]
|
|
[[grant-user-access-basic]]
|
|
=== Grant users access with a Basic license
|
|
|
|
With a Basic license, you can grant users access with custom roles to {report-features} with <<kibana-privileges, {kib} application privileges>>. However, with a Basic license, sub-feature privileges are unavailable. <<grant-user-access,Create a role>>, then select *All* privileges for the applications where users can create reports.
|
|
|
|
[role="screenshot"]
|
|
image::user/reporting/images/kibana-privileges-with-reporting-basic.png["Kibana privileges with Reporting options, Basic license"]
|
|
|
|
With a Basic license, sub-feature application privileges are unavailable, but you can use the {ref}/security-api-put-role.html[role API] to grant access to CSV {report-features}:
|
|
|
|
[source, sh]
|
|
---------------------------------------------------------------
|
|
PUT localhost:5601/api/security/role/custom_reporting_user
|
|
{
|
|
"elasticsearch": { "cluster": [], "indices": [], "run_as": [] },
|
|
"kibana": [
|
|
{
|
|
"base": [],
|
|
"feature": {
|
|
"dashboard_v2": [ "all" ], <1>
|
|
"discover_v2": [ "all" ], <2>
|
|
},
|
|
"spaces": [ "*" ]
|
|
}
|
|
],
|
|
"metadata": {} // optional
|
|
}
|
|
---------------------------------------------------------------
|
|
// CONSOLE
|
|
|
|
<1> Grants access to generate CSV reports from saved Discover sessions in *Discover*.
|
|
<2> Grants access to generate CSV reports from saved Discover session panels in *Dashboard*.
|
|
|
|
[float]
|
|
[[grant-user-access-external-provider]]
|
|
==== Grant access using an external provider
|
|
|
|
If you are using an external identity provider, such as LDAP or Active Directory, you can assign roles to individual users or groups of users. Role mappings are configured in {ref}/mapping-roles.html[`config/role_mapping.yml`].
|
|
|
|
For example, assign the `kibana_admin` and `reporting_user` roles to the Bill Murray user:
|
|
|
|
[source,yaml]
|
|
--------------------------------------------------------------------------------
|
|
kibana_admin:
|
|
- "cn=Bill Murray,dc=example,dc=com"
|
|
reporting_user:
|
|
- "cn=Bill Murray,dc=example,dc=com"
|
|
--------------------------------------------------------------------------------
|
|
|
|
[float]
|
|
[[securing-reporting]]
|
|
=== Secure the reporting endpoints
|
|
|
|
To automatically generate reports with {watcher}, you must configure {watcher} to trust the {kib} server certificate.
|
|
|
|
. Enable {stack-security-features} on your {es} cluster. For more information, see {ref}/security-getting-started.html[Getting started with security].
|
|
|
|
. Configure TLS/SSL encryption for the {kib} server. For more information, see <<configuring-tls>>.
|
|
|
|
. Specify the {kib} server CA certificate chain in `elasticsearch.yml`:
|
|
+
|
|
--
|
|
If you are using your own CA to sign the {kib} server certificate, then you need to specify the CA certificate chain in {es} to properly establish trust in TLS connections between {watcher} and {kib}. If your CA certificate chain is contained in a PKCS #12 trust store, specify it like so:
|
|
|
|
[source,yaml]
|
|
--------------------------------------------------------------------------------
|
|
xpack.http.ssl.truststore.path: "/path/to/your/truststore.p12"
|
|
xpack.http.ssl.truststore.type: "PKCS12"
|
|
xpack.http.ssl.truststore.password: "optional decryption password"
|
|
--------------------------------------------------------------------------------
|
|
|
|
Otherwise, if your CA certificate chain is in PEM format, specify it like so:
|
|
|
|
[source,yaml]
|
|
--------------------------------------------------------------------------------
|
|
xpack.http.ssl.certificate_authorities: ["/path/to/your/cacert1.pem", "/path/to/your/cacert2.pem"]
|
|
--------------------------------------------------------------------------------
|
|
|
|
For more information, see {ref}/notification-settings.html#ssl-notification-settings[the {watcher} HTTP TLS/SSL Settings].
|
|
--
|
|
|
|
. Add one or more users who have access to the {report-features}.
|
|
+
|
|
Once you've enabled SSL for {kib}, all requests to the reporting endpoints must include valid credentials.
|
|
|
|
For more information on sharing reports, direct links, and more, refer to <<reporting-getting-started, Reporting and sharing>>.
|
|
|
|
[float]
|
|
[[install-reporting-packages]]
|
|
=== Install the dependencies for the headless browser
|
|
|
|
If using PNG/PDF {report-features}, make sure the {kib} server operating system has the appropriate packages installed for the distribution.
|
|
|
|
If you are using RHEL operating systems, install the following packages:
|
|
|
|
* `xorg-x11-fonts-100dpi`
|
|
* `xorg-x11-fonts-75dpi`
|
|
* `xorg-x11-utils`
|
|
* `xorg-x11-fonts-cyrillic`
|
|
* `xorg-x11-fonts-Type1`
|
|
* `xorg-x11-fonts-misc`
|
|
* `vlgothic-fonts`
|
|
* `fontconfig`
|
|
* `freetype`
|
|
|
|
If you are using Ubuntu/Debian systems, install the following packages:
|
|
|
|
* `fonts-liberation`
|
|
* `libfontconfig1`
|
|
* `libnss3`
|
|
|
|
The screenshotting plugin used for {reporting-features} has a built-in utility to check for common issues, such as missing dependencies. See
|
|
<<reporting-diagnostics>> for more information.
|
|
|
|
[float]
|
|
[[set-reporting-server-host]]
|
|
=== Set the `server.host` for the headless browser
|
|
|
|
If using PNG/PDF {report-features} in a production environment, it is preferred to use the setting of
|
|
`server.host: 0.0.0.0` in the `kibana.yml` configuration file. This allows the headless browser used for
|
|
PDF/PNG reporting to reach {kib} over a local interface, while also allowing the {kib} server to listen on
|
|
outward-facing network interfaces, as it makes the {kib} server accessible from any network interface on the
|
|
machine. Make sure that no firewall rules or other routing rules prevent local services from accessing this
|
|
address.
|
|
|
|
[float]
|
|
[[reporting-elasticsearch-configuration]]
|
|
=== Ensure {es} allows built-in templates
|
|
Reporting relies on {es} to install a mapping template for the data stream that stores reports. Ensure that {es} allows built-in
|
|
templates to be installed by keeping the `stack.templates.enabled` setting at the default value of `true`. For more information, see
|
|
{ref}/index-management-settings.html#stack-templates-enabled[Index management settings].
|