213 lines
8.9 KiB
Text
213 lines
8.9 KiB
Text
[role="xpack"]
|
|
[[secure-reporting]]
|
|
=== Reporting and security
|
|
|
|
Reporting operates by creating and updating documents in {es} in response to
|
|
user actions in {kib}.
|
|
|
|
To use {report-features} with {security-features} enabled, you need to
|
|
<<using-kibana-with-security,configure security in {kib}>>.
|
|
If you are automatically generating reports with
|
|
{ref}/xpack-alerting.html[{watcher}], you also need to configure {watcher}
|
|
to trust the {kib} server's certificate.
|
|
////
|
|
For more information, see
|
|
<<securing-reporting>>.
|
|
////
|
|
|
|
[[reporting-app-users]]
|
|
Access to reporting features is limited to privileged users. In older versions of Kibana, you could only grant
|
|
users the privilege by assigning them the `reporting_user` role in Elasticsearch. In 7.14 and above, you have
|
|
the option to create your own roles that grant access to reporting features using <<kibana-privileges, {kib} privileges>>.
|
|
|
|
It is recommended that you set `xpack.reporting.roles.enabled: false` in your kibana.yml to begin using Kibana
|
|
privileges. This will allow users to only see Reporting widgets in applications when they have privilege to use
|
|
them.
|
|
|
|
[NOTE]
|
|
============================================================================
|
|
The default value of `xpack.reporting.roles.enabled` is `true` for 7.x versions of Kibana. To migrate users to the
|
|
new method of securing access to *Reporting*, you must explicitly set `xpack.reporting.roles.enabled: false` in
|
|
`kibana.yml`. In the next major version of Kibana, having this set to `false` will be the only valid configuration.
|
|
============================================================================
|
|
|
|
This document discusses how to create a role that grants access to reporting features using the new method of
|
|
Kibana application privileges.
|
|
|
|
[float]
|
|
[[reporting-roles-management-ui]]
|
|
=== Create the role in the `native` realm
|
|
|
|
To create roles, use the *Roles* UI or <<reporting-roles-user-api, user API>>. This example shows how to
|
|
create a role that grants reporting feature privileges in {kib} applications.
|
|
|
|
. Open the main menu, then click *Stack Management > Roles*.
|
|
|
|
. Click *Create role*, then give the role a name, for example, `custom_reporting_user`.
|
|
|
|
. Specify the indices and privileges.
|
|
+
|
|
Access to data is an index-level privilege, so in *Create role*,
|
|
add a line for each index that contains the data for the report and give each
|
|
index `read` and `view_index_metadata` privileges.
|
|
For more information, see {ref}/security-privileges.html[Security privileges].
|
|
+
|
|
[role="screenshot"]
|
|
image::user/security/images/reporting-privileges-example.png["Reporting privileges"]
|
|
|
|
. Add space privileges for the {kib} applications that allow access to the reporting options.
|
|
+
|
|
To allow users to create CSV reports in *Discover*, or PDF reports in *Canvas*,
|
|
*Visualize Library*, and *Dashboard*, click *Add Kibana privilege* for each application,
|
|
then select the privileges to generate
|
|
reports. For example, select *All* privileges for all features, or *Customize* to grant
|
|
the privilege to generate reports for only specific applications.
|
|
+
|
|
[role="screenshot"]
|
|
image::user/security/images/reporting-custom-role.png["Reporting custom role"]
|
|
+
|
|
[NOTE]
|
|
============================================================================
|
|
Granting users access to reporting features in any application also grants them access to manage their reports in *Stack Management > Reporting*.
|
|
============================================================================
|
|
+
|
|
. Save your new role.
|
|
|
|
. Open the main menu, then click *Stack Management > Users*, add a new user, and assign the user
|
|
your new `custom_reporting_user` role.
|
|
|
|
[float]
|
|
[[reporting-roles-user-api]]
|
|
==== With the user API
|
|
This example uses the {ref}/security-api-put-role.html[role API] to create a role that
|
|
grants the privilege to generate reports in *Canvas*, *Discover*, *Visualize Library*, and *Dashboard*.
|
|
This role is meant to be granted to users in combination with other roles that grant read access
|
|
to the data in {es}, and at least read access in the applications
|
|
where they'll generate reports.
|
|
|
|
[source, sh]
|
|
---------------------------------------------------------------
|
|
POST /_security/role/custom_reporting_user
|
|
{
|
|
metadata: {},
|
|
elasticsearch: { cluster: [], indices: [], run_as: [] },
|
|
kibana: [
|
|
{
|
|
base: [],
|
|
feature: {
|
|
dashboard: [
|
|
'generate_report', <1>
|
|
'download_csv_report' <2>
|
|
],
|
|
discover: ['generate_report'], <3>
|
|
canvas: ['generate_report'], <4>
|
|
visualize: ['generate_report'], <5>
|
|
},
|
|
spaces: ['*'],
|
|
}
|
|
]
|
|
}
|
|
---------------------------------------------------------------
|
|
// CONSOLE
|
|
|
|
<1> Grants access to generate PNG and PDF reports in *Dashboard*.
|
|
<2> Grants access to download CSV files from saved search panels in *Dashboard*.
|
|
<3> Grants access to generate CSV reports from saved searches in *Discover*.
|
|
<4> Grants access to generate PDF reports in *Canvas*.
|
|
<5> Grants access to generate PNG and PDF reports in *Visualize Library*.
|
|
|
|
[float]
|
|
=== When using an external provider
|
|
|
|
If you are using an external identity provider, such as
|
|
LDAP or Active Directory, you can either assign
|
|
roles on a per user basis, or assign roles to groups of users. By default, role
|
|
mappings are configured in
|
|
{ref}/mapping-roles.html[`config/role_mapping.yml`].
|
|
For example, the following snippet assigns the user named Bill Murray the
|
|
`kibana_admin` and `reporting_user` roles:
|
|
|
|
[source,yaml]
|
|
--------------------------------------------------------------------------------
|
|
kibana_admin:
|
|
- "cn=Bill Murray,dc=example,dc=com"
|
|
reporting_user:
|
|
- "cn=Bill Murray,dc=example,dc=com"
|
|
--------------------------------------------------------------------------------
|
|
|
|
[float]
|
|
=== With a custom index
|
|
|
|
If you are using a custom index,
|
|
the `xpack.reporting.index` setting should begin
|
|
with `.reporting-*`. The default {kib} system user has
|
|
`all` privileges against the `.reporting-*` pattern of indices.
|
|
|
|
[source,js]
|
|
xpack.reporting.index: '.reporting-custom-index'
|
|
|
|
If you use a different pattern for the `xpack.reporting.index` setting,
|
|
you must create a custom `kibana_system` user with appropriate access to the index, similar
|
|
to the following:
|
|
|
|
. Open the main menu, then click *Stack Management > Roles*.
|
|
. Click *Create role*, then name the role `custom-reporting-user`.
|
|
. Specify the custom index and assign it the `all` index privilege.
|
|
. Open the main menu, then click *Stack Management > Users* and create a new user with
|
|
the `kibana_system` role and the `custom-reporting-user` role.
|
|
. Configure {kib} to use the new account:
|
|
[source,js]
|
|
elasticsearch.username: 'custom_kibana_system'
|
|
|
|
[NOTE]
|
|
============================================================================
|
|
Setting a custom index for *Reporting* is not supported in the next major version of Kibana.
|
|
============================================================================
|
|
|
|
[role="xpack"]
|
|
[[securing-reporting]]
|
|
=== Secure the reporting endpoints
|
|
|
|
In a production environment, you should restrict access to
|
|
the reporting endpoints to authorized users. This requires that you:
|
|
|
|
. 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's 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 the permissions
|
|
necessary to use {kib} and {report-features}. For more information, see
|
|
<<secure-reporting>>.
|
|
|
|
Once you've enabled SSL for {kib}, all requests to the reporting endpoints
|
|
must include valid credentials. For example, see the following page which
|
|
includes a watch that submits requests as the built-in `elastic` user:
|
|
<<automating-report-generation>>.
|
|
|
|
For more information about configuring watches, see
|
|
{ref}/how-watcher-works.html[How {watcher} works].
|