Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pre-configured Connectors #58914

Closed
peterschretlen opened this issue Feb 28, 2020 · 2 comments · Fixed by #63074
Closed

Pre-configured Connectors #58914

peterschretlen opened this issue Feb 28, 2020 · 2 comments · Fixed by #63074
Assignees
Labels
Feature:Actions Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)

Comments

@peterschretlen
Copy link
Contributor

Describe a specific use case for the feature:

Today, connectors for actions are created in the UI or via API. We’d like to add the ability to pre-configure connectors, before Kibana has even started:

  • For out-of-the-box connectors - for example in Elastic Cloud deployments - that need no configuration.
  • For standardized connectors in templated deployments like Kubernetes, so that multiple clusters have identical connectors.
  • For cluster admins that prefer to control all external connections via Kibana.yml for security purposes.

Describe the feature:

A “preconfigured” connector would be different from a regular connector in the following ways:

  • They must require zero setup. Configuration and secrets/credentials needed to execute an action are pre-defined, including the connector name and id.
  • They automatically appear in all spaces. Unlike regular connectors, pre-configured connectors are not stored as saved objects.
  • They cannot be edited or deleted in the API or in the UI

Pre-configured connectors are defined in Kibana.yml or directly in code. Sensitive configuration like credentials can use either kibana.yml or the Kibana keystore.

Because these connectors have all the information they need to execute prior to startup, a saved object representation isn’t necessary. They can be stored in-memory on each Kibana server instance.

Example:

Say I’d like to provide 4 out of the box connectors:

  • “Slack #xyz” - using the slack built-in action type
  • “Slack #123” - using the slack built-in action type
  • “Email service” - uses the built in webhook type to send an email via API
  • “System ABC” - is a custom action type ( could be a cloud connector for example )

Kibana.yml

These connectors would be setup in kibana.yml as follows. Note sensitive properties like passwords can also be stored in the Kibana keystore:

xpack.actions.preconfigured:
 - my-slack1: #this becomes the action/connector id
   actionTypeId: .slack #use the built in slack action type
   name: 'Slack #xyz'
   description: 'Send a message to the #xyz channel'
   # sensitive config like secrets are preferably stored in Kibana keystore
   config:
     webhookUrl: 'https://hooks.slack.com/services/abcd/efgh/ijklmnopqrstuvwxyz'
 
 - my-slack2: 
   actionTypeId: .slack
   name: 'Slack #123 '
   description: 'Send a message to the #123 channel'
   config:
     webhookUrl: 'https://hooks.slack.com/services/01234/567890/01234567890'
 
 - email-service: 
   actionTypeId: .webhook #use the built-in webhook action type 
   # everything below is .webhook action type configuration
   name: 'Email service'
   description: 'Notify the cloud monitoring email list'
   config:
     url: 'https://email-alert-service.elastic.co'
     method: post
     headers:
       header1: value1
       header2: value2
   secrets:
     user: elastic
     password: changeme
 
 - custom-system-abc-connector:
   actionTypeId: system-abc-action-type #this a custom action type written as a plugin
   description: 'Send a notification to system ABC'
   name: 'System ABC'
   config:
     xyzConfig1: value1
     xyzConfig2: value2
     listOfThings: [a,b,c,d]
   # sensitive config like secrets are preferably stored in Kibana keystore
   secrets:
     xyzSecret1: credential1
     xyzSecret2: credential2

Creating an alert with a pre-configured connector

When a user attaches an action to their alert, they select from a list of available action types.
image

Select the Slack type. Even though I haven’t yet created a connector, because a pre-configured connector is installed, it’s automatically selected:
image

The dropdown is populated with other pre-configured slack connectors
image

The “pre-configured” label distinguishes them from space-aware connectors that use saved objects:
image

Managing pre-configured connectors

Pre-configured connectors appear in the connector list, regardless of which space the user is in. They are tagged as “pre-configured” and cannot be deleted. Note I've listed Server Log here as a pre-configured connector, it should be converted to one.
image

Clicking on a pre-configured connector will show the description but not any of the configuration. A message indicates that this is a pre-configured connector and cannot be edited.
image

When action types are registered, they can indicate if they can allow pre-configuration, configuration at runtime, or both. In this case, the “Server Log” and “System ABC” action types allow pre-configuration only, so are excluded from the list when creating new connectors:
image

@peterschretlen peterschretlen added Feature:Actions Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) labels Feb 28, 2020
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-alerting-services (Team:Alerting Services)

@peterschretlen
Copy link
Contributor Author

Related: #56433

"Default actions" for managed versions of the stack (ESS/ECE/ECK) would be implemented as pre-configured connectors

@YulNaumenko YulNaumenko self-assigned this Apr 1, 2020
@kobelb kobelb added the needs-team Issues missing a team label label Jan 31, 2022
@botelastic botelastic bot removed the needs-team Issues missing a team label label Jan 31, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:Actions Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants