Configure reporting in Kibana

For security, you grant users access to the reporting features and secure the reporting endpoints with TLS/SSL encryption. Additionally, you can install graphical packages into the operating system to enable the Kibana server to have screenshotting capabilities.

Make sure the Kibana server operating system has the appropriate packages installed for the distribution.

If you are using CentOS/RHEL systems, install the following packages:

If you are using Ubuntu/Debian systems, install the following packages:

If the system is missing dependencies, a screenshot report job may fail in a non-deterministic way. Kibana runs a self-test at server startup, and if it encounters errors, logs them in the Console. The error message does not include information about why Chromium failed to run. The most common error message is Error: connect ECONNREFUSED, which indicates that Kibana could not connect to the Chromium process.

To troubleshoot the problem, start the Kibana server with environment variables that tell Chromium to print verbose logs. For more information, refer to Puppeteer debug logs.

When security is enabled, you grant users access to generate reports with Kibana application privileges, which allow you to create custom roles that control the spaces and applications where users generate reports.

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.

With Kibana application privileges enabled in Reporting, you can also use the role API to grant access to the reporting features, using All privileges, or sub-feature privileges.

POST <kibana host>:<port>/api/_security/role/custom_reporting_user
{
	"elasticsearch": {
		"cluster": [],
		"indices": [],
		"run_as": []
	},
	"kibana": [{
		"spaces": ["*"],
		"base": [],
		"feature": {
			"dashboard": ["generate_report",  
      "download_csv_report"], 
      "discover": ["generate_report"], 
			"canvas": ["generate_report"], 
			"visualize": ["generate_report"] 
		}
	}]
}

With a Basic license, you can grant users access with custom roles to reporting features with Kibana application privileges. However, with a Basic license, sub-feature privileges are unavailable. Create a role, then select All privileges for the applications where users can create reports.

With a Basic license, sub-feature application privileges are unavailable, but you can use the role API to grant access to CSV reporting features:

PUT localhost:5601/api/security/role/custom_reporting_user
{
  "elasticsearch": { "cluster": [], "indices": [], "run_as": [] },
  "kibana": [
    {
      "base": [],
      "feature": {
        "dashboard": [ "all" ], 
        "discover": [ "all" ], 
      },
      "spaces": [ "*" ]
    }
  ],
  "metadata": {} // optional
}

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 config/role_mapping.yml.

For example, assign the kibana_admin and reporting_user roles to the Bill Murray user:

kibana_admin:
  - "cn=Bill Murray,dc=example,dc=com"
reporting_user:
  - "cn=Bill Murray,dc=example,dc=com"

If you are using a custom index, the xpack.reporting.index setting must begin with .reporting-*. The default Kibana system user has all privileges against the .reporting-* pattern of indices.

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.

To automatically generate reports with Watcher, you must configure Watcher to trust the Kibana server certificate.