Reporting settings in Kibana

You can configure xpack.reporting settings in your kibana.yml to:

By default, an encryption key is generated for the reporting features each time you start Kibana. If a static encryption key is not persisted in the Kibana configuration, any pending reports fail when you restart Kibana.

If you are load balancing across multiple Kibana instances, each instance needs to have the same reporting encryption key. Otherwise, report generation fails if a report is queued through one instance, and another instance picks up the job from the report queue. The instance that picks up the job is unable to decrypt the reporting job metadata.

xpack.reporting.encryptionKey: "something_secret"

Kibana instance A:

kibana.index: ".kibana-a"
xpack.reporting.index: ".reporting-a"
xpack.reporting.encryptionKey: "something_secret"

Kibana instance B:

kibana.index: ".kibana-b"
xpack.reporting.index: ".reporting-b"
xpack.reporting.encryptionKey: "something_secret"

Reporting opens the Kibana web interface in a server process to generate screenshots of Kibana visualizations. In most cases, the default settings work and you don’t need to configure the reporting features to communicate with Kibana.

If your Kibana instance requires a reverse proxy (such as NGINX, Apache, etc.) for access, because of rewrite rules or special headers being added by the proxy, you must configure the xpack.reporting.kibanaServer settings to make the headless browser process connect to the proxy.

Reporting generates reports in the background and jobs are coordinated using documents in Elasticsearch. Depending on how often you generate reports and the overall number of reports, you might need to change the following settings.

Reporting works by capturing screenshots from Kibana. The following settings control the capturing process.

When xpack.reporting.capture.browser.type is set to chromium (default) you can also specify the following settings.

To generate PDF reports, Reporting uses the Chromium browser to fully load the Kibana page on the server. This potentially involves sending requests to external hosts. For example, a request might go to an external image server to show a field formatted as an image, or to show an image in a Markdown visualization.

If the Chromium browser is asked to send a request that violates the network policy, Reporting stops processing the page before the request goes out, and the report is marked as a failure. Additional information about the event is in the Kibana server logs.

The rule objects are evaluated sequentially from the beginning to the end of the array, and continue until there is a matching rule. If no rules allow a request, the request is denied.

# Only allow requests to placeholder.com
xpack.reporting.capture.networkPolicy:
  rules: [ { allow: true, host: "placeholder.com" } ]

# Only allow requests to https://placeholder.com
xpack.reporting.capture.networkPolicy:
  rules: [ { allow: true, host: "placeholder.com", protocol: "https:" } ]

A final allow rule with no host or protocol allows all requests that are not explicitly denied:

# Denies requests from http://placeholder.com, but anything else is allowed.
xpack.reporting.capture.networkPolicy:
  rules: [{ allow: false, host: "placeholder.com", protocol: "http:" }, { allow: true }];

A network policy can be composed of multiple rules:

# Allow any request to http://placeholder.com but for any other host, https is required
xpack.reporting.capture.networkPolicy
  rules: [
    { allow: true, host: "placeholder.com", protocol: "http:" },
    { allow: true, protocol: "https:" },
  ]

With Security enabled, Reporting has two forms of access control: each user can only access their own reports, and custom roles determine who has privilege to generate reports. When Reporting is configured with Kibana application privileges, you can control the spaces and applications where users are allowed to generate reports.