Elastic Docs ›Kibana Guide ›Stack Management ›Connectors
« D3 Security connector and action License Management »

Preconfigured connectorsedit

If you are running Kibana on-prem, you can preconfigure a connector to have all the information it needs prior to startup by adding it to the kibana.yml file.

Elasticsearch Service provides a preconfigured email connector but you cannot create additional preconfigured connectors.

Preconfigured connectors offer the following benefits:

  • Require no setup. Configuration and credentials needed to run an action are predefined, including the connector name and ID.
  • Appear in all spaces because they are not saved objects.
  • Cannot be edited or deleted.

Create preconfigured connectorsedit

Add xpack.actions.preconfigured settings to your kibana.yml file. The settings vary depending on which type of connector you’re adding.

This example shows a valid configuration for a Slack connector and a Webhook connector:

  xpack.actions.preconfigured:
    my-slack1:                  
      actionTypeId: .slack      
      name: 'Slack #xyz'        
      secrets:
        webhookUrl: 'https://hooks.slack.com/services/abcd/efgh/ijklmnopqrstuvwxyz'
    webhook-service:
      actionTypeId: .webhook
      name: 'Email service'
      config:                   
        url: 'https://email-alert-service.elastic.co'
        method: post
        headers:
          header1: value1
          header2: value2
      secrets:                  
        user: elastic
        password: changeme

The key is the connector identifier, my-slack1 in this example.

actionTypeId is the action type identifier.

name is the name of the preconfigured connector.

config is the configuration specific to the connector type.

secrets is the sensitive configuration, such as username, password, and keys, specific to the connector type.

Sensitive properties, such as passwords, can also be stored in the Kibana keystore.

View preconfigured connectorsedit

When you open the main menu, click Stack Management > Connectors. Preconfigured connectors appear regardless of which space you are in. They are tagged as “preconfigured”, and you cannot delete them.

Connectors managing tab with pre-configured

Clicking a preconfigured connector shows the description, but not the configuration.

Built-in preconfigured connectorsedit

Kibana provides the following built-in preconfigured connectors:

Preconfigured alert history Elasticsearch index connectoredit

This functionality is in technical preview and may be changed or removed in a future release. Elastic will apply best effort to fix any issues, but features in technical preview are not subject to the support SLA of official GA features.

Kibana offers a preconfigured index connector to facilitate indexing active alert data into Elasticsearch. To use this connector, set xpack.actions.preconfiguredAlertHistoryEsIndex to true.

When you subsequently create rules, you can use the Alert history Elasticsearch index (preconfigured) connector.

Creating a rule action that uses the pre-configured alert history connector

Documents are indexed using a preconfigured schema that captures the action variables available for the rule. By default, these documents are indexed into the kibana-alert-history-default index, but you can specify a different index. Index names must start with kibana-alert-history- to take advantage of the preconfigured alert history index template.

  • To write documents to the preconfigured index, you must have all or write privileges to the kibana-alert-history-* indices.
  • The kibana-alert-history-* indices are not configured to use ILM so they must be maintained manually. If the index size grows large, consider using the delete by query API to clean up older documents in the index.

Examplesedit

Index connectorsedit

The following example creates a index connector:

xpack.actions.preconfigured:
  my-index:
    name: preconfigured-index-connector-type
    actionTypeId: .index
    config:
      index: .kibana 
      executionTimeField: my-field

The Elasticsearch index to be written to.

A field that indicates when the document was indexed.
Jira connectorsedit

The following example creates a Jira connector:

xpack.actions.preconfigured:
  my-jira:
    name: preconfigured-jira-connector-type
    actionTypeId: .jira
    config:
      apiUrl: https://elastic.atlassian.net 
      projectKey: ES 
    secrets:
      email: testuser 
      apiToken: tokenkeystorevalue

The Jira instance URL.

The Jira project key.

The account email for HTTP basic authentication.

The API authentication token for HTTP basic authentication. NOTE: This value should be stored in the Kibana keystore.
Opsgenie connectorsedit

The following example creates an Opsgenie connector:

xpack.actions.preconfigured:
  my-opsgenie:
    name: preconfigured-opsgenie-connector-type
    actionTypeId: .opsgenie
    config:
      apiUrl: https://api.opsgenie.com 
    secrets:
      apiKey: apikey

The Opsgenie URL.

The Opsgenie API authentication key for HTTP basic authentication.
PagerDuty connectorsedit

The following example creates a PagerDuty connector:

xpack.actions.preconfigured:
  my-pagerduty:
    name: preconfigured-pagerduty-connector-type
    actionTypeId: .pagerduty
    config:
      apiUrl: https://test.host 
    secrets:
      routingKey: testroutingkey

The PagerDuty event URL.

A 32 character PagerDuty Integration Key for an integration on a service, also referred to as the routing key.
Server log connectorsedit

The following example creates a server log connector:

xpack.actions.preconfigured:
  my-server-log:
    name: preconfigured-server-log-connector-type
    actionTypeId: .server-log
Webhook connectorsedit

The following example creates a webhook connector with basic authentication:

xpack.actions.preconfigured:
  my-webhook:
    name: preconfigured-webhook-connector-type
    actionTypeId: .webhook
    config:
      url: https://test.host 
      method: post 
      headers: 
        testheader: testvalue
      hasAuth: true 
    secrets:
      user: testuser 
      password: passwordkeystorevalue

The web service request URL. If you are using the xpack.actions.allowedHosts setting, make sure the hostname is added to the allowed hosts.

The HTTP request method, either post(default) or put.

A set of key-value pairs sent as headers with the request.

If true, this connector will require values for user and password inside the secrets configuration. Defaults to true.

A valid user name. Required if hasAuth is set to true.

A valid password. Required if hasAuth is set to true. NOTE: This value should be stored in the Kibana keystore.

SSL authentication is not supported in preconfigured webhook connectors.

Webhook - Case Management connectorsedit

The following example creates a Webhook - Case Management connector:

xpack.actions.preconfigured:
  my-case-management-webhook:
    name: Case Management Webhook Connector
    actionTypeId: .cases-webhook
    config:
      hasAuth: true 
      headers: 
        'content-type': 'application/json'
      createIncidentUrl: 'https://testing-jira.atlassian.net/rest/api/2/issue' 
      createIncidentMethod: 'post' 
      createIncidentJson: '{"fields":{"summary":{{{case.title}}},"description":{{{case.description}}},"labels":{{{case.tags}}}' 
      getIncidentUrl: 'https://testing-jira.atlassian.net/rest/api/2/issue/{{{external.system.id}}}' 
      getIncidentResponseExternalTitleKey: 'key' 
      viewIncidentUrl: 'https://testing-jira.atlassian.net/browse/{{{external.system.title}}}' 
      updateIncidentUrl: 'https://testing-jira.atlassian.net/rest/api/2/issue/{{{external.system.id}}}' 
      updateIncidentMethod: 'put' 
      updateIncidentJson: '{"fields":{"summary":{{{case.title}}},"description":{{{case.description}}},"labels":{{{case.tags}}}' 
      createCommentMethod: 'post', 
      createCommentUrl: 'https://testing-jira.atlassian.net/rest/api/2/issue/{{{external.system.id}}}/comment', 
      createCommentJson: '{"body": {{{case.comment}}}}', 
    secrets:
      user: testuser 
      password: passwordvalue

If true, this connector will require values for user and password inside the secrets configuration.

A set of key-value pairs sent as headers with the request.

A REST API URL string to create a case in the third-party system.

The REST API HTTP request method to create a case in the third-party system.

A stringified JSON payload with Mustache variables that is sent to the create case URL to create a case.

A REST API URL string with an external service ID Mustache variable to get the case from the third-party system.

A string from the response body of the get case method that corresponds to the external service title.

A URL string with either the external service ID or external service title Mustache variable to view a case in the external system.

The REST API URL to update the case by ID in the third-party system.

The REST API HTTP request method to update the case in the third-party system.

A stringified JSON payload with Mustache variables that is sent to the update case URL to update a case.

The REST API HTTP request method to create a case comment in the third-party system.

A REST API URL string to create a case comment by ID in the third-party system.

A stringified JSON payload with Mustache variables that is sent to the create comment URL to create a case comment.

A user name, which is required when hasAuth is true.

A password, which is required when hasAuth is true.
« D3 Security connector and action License Management »