Alerting and action settings in Kibana

A string of 32 or more characters used to encrypt sensitive properties on alerting rules and actions before they’re stored in Elasticsearch. Third party credentials — such as the username and password used to connect to an SMTP service — are an example of encrypted properties.

Kibana offers a CLI tool to help generate this encryption key.

If not set, Kibana will generate a random key on startup, but all alerting and action functions will be blocked. Generated keys are not allowed for alerting and actions because when a new key is generated on restart, existing encrypted data becomes inaccessible. For the same reason, alerting and actions in high-availability deployments of Kibana will behave unexpectedly if the key isn’t the same on all instances of Kibana.

Although the key can be specified in clear text in kibana.yml, it’s recommended to store this key securely in the Kibana Keystore. Be sure to back up the encryption key value somewhere safe, as your alerting rules and actions will cease to function due to decryption failures should you lose it. If you want to rotate the encryption key, be sure to follow the instructions on encryption key rotation.

A list of hostnames that Kibana is allowed to connect to when built-in actions are triggered. It defaults to [*], allowing any host, but keep in mind the potential for SSRF attacks when hosts are not explicitly added to the allowed hosts. An empty list [] can be used to block built-in actions from making any external connections.

Note that hosts associated with built-in actions, such as Slack and PagerDuty, are not automatically added to allowed hosts. If you are not using the default [*] setting, you must ensure that the corresponding endpoints are added to the allowed hosts as well.

A list of custom host settings to override existing global settings. Default: an empty list.

Each entry in the list must have a url property, to associate a connection type (mail or https), hostname and port with the remaining options in the entry.

In the following example, two custom host settings are defined. The first provides a custom host setting for mail server mail.example.com using port 465 that supplies server certificate authentication data from both a file and inline, and requires TLS for the connection. The second provides a custom host setting for https server webhook.example.com which turns off server certificate authentication, that will allow Kibana to connect to the server if it’s using a self-signed certificate. The individual properties that can be used in the settings are documented below.

xpack.actions.customHostSettings:
  - url: smtp://mail.example.com:465
    ssl:
      verificationMode: 'full'
      certificateAuthoritiesFiles: [ 'one.crt' ]
      certificateAuthoritiesData: |
          -----BEGIN CERTIFICATE-----
          ... multiple lines of certificate data here ...
          -----END CERTIFICATE-----
    smtp:
      requireTLS: true
  - url: https://webhook.example.com
    ssl:
      verificationMode: 'none'

A URL associated with this custom host setting. Should be in the form of protocol://hostname:port, where protocol is https or smtp. If the port is not provided, 443 is used for https and 25 is used for smtp. The smtp URLs are used for the Email actions that use this server, and the https URLs are used for actions which use https to connect to services.

Entries with https URLs can use the ssl options, and entries with smtp URLs can use both the ssl and smtp options.

No other URL values should be part of this URL, including paths, query strings, and authentication information. When an http or smtp request is made as part of running an action, only the protocol, hostname, and port of the URL for that request are used to look up these configuration values.

A list of action types that are enabled. It defaults to [*], enabling all types. The names for built-in Kibana action types are prefixed with a . and include: .email, .index, .jira, .pagerduty, .resilient, .server-log, .servicenow, .servicenow-itom, .servicenow-sir, .slack, .swimlane, .teams, .xmatters, and .webhook. An empty list [] will disable all action types.

Disabled action types will not appear as an option when creating new connectors, but existing connectors and actions of that type will remain in Kibana and will not function.

Deprecated. Use xpack.actions.ssl.verificationMode instead. Set to false to bypass certificate validation for actions. Default: true.

As an alternative to setting xpack.actions.rejectUnauthorized, you can use the setting xpack.actions.customHostSettings to set SSL options for specific servers.

Controls the verification for the server certificate that Elastic Maps Server receives when making an outbound SSL/TLS connection for actions. Valid values are full, certificate, and none. Use full to perform hostname verification, certificate to skip hostname verification, and none to skip verification. Default: full. Equivalent Kibana setting.

This setting can be overridden for specific URLs by using the setting xpack.actions.customHostSettings[n].ssl.verificationMode (described above) to a different value.

Specifies the time allowed for requests to external resources. Requests that take longer are aborted. The time is formatted as:

<count>[ms,s,m,h,d,w,M,Y]

For example, 20m, 24h, 7d, 1w. Default: 60s.

Specifies the minimum schedule interval for rules. This minimum is applied to all rules created or updated after you set this value. The time is formatted as:

<count>[s,m,h,d]

For example, 20m, 24h, 7d. Default: 1m.

Specifies the default timeout for tasks associated with all types of rules. The time is formatted as:

<count>[ms,s,m,h,d,w,M,Y]

For example, 20m, 24h, 7d, 1w. Default: 5m.

Overrides the configs under xpack.alerting.rules.run for the rule type with the given ID. List the rule identifier and its settings in an array of objects.

For example:

xpack.alerting.rules.run:
    timeout: '5m'
    ruleTypeOverrides:
        - id: '.index-threshold'
          timeout: '15m'