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 not easy to configure in kibana.yml #63171

Closed
mikecote opened this issue Apr 9, 2020 · 4 comments · Fixed by #65397
Closed

Pre-configured connectors not easy to configure in kibana.yml #63171

mikecote opened this issue Apr 9, 2020 · 4 comments · Fixed by #65397
Labels
Feature:Alerting Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)

Comments

@mikecote
Copy link
Contributor

mikecote commented Apr 9, 2020

The xpack.actions.preconfigured kibana.yml configuration currently accepts an array of objects but doesn't make it easy to configure in YML. Using for example a collection, it would be more natural to configure like the following example:

xpack.actions.preconfigured:
  - foo:
    name: Foo
    actionTypeId: .server-log
    config:
      param1: test
@mikecote mikecote added Feature:Alerting Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) labels Apr 9, 2020
@elasticmachine
Copy link
Contributor

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

@pmuellr
Copy link
Member

pmuellr commented Apr 9, 2020

Here's what I'm using, which works as far as I can tell:

xpack.actions.preconfigured:
- id: 'slack'
  name: 'slack'
  actionTypeId: '.slack'
  config: 
    webhookUrl: 'https://hooks.slack.com/services/super/secret/here'
- id: 'server-log'
  name: 'server log'
  actionTypeId: '.server-log'
- id: 'maildev auth'
  name: 'email: maildev auth'
  actionTypeId: '.email'
  config:
    from: 'pmuellr@example.com'
    host: 'localhost'
    port: '1025'
  secrets:
    user: 'elastic'
    password: 'changeme'
- id: 'maildev no auth'
  name: 'email: maildev no auth'
  actionTypeId: '.email'
  config:
    from: 'pmuellr@example.com'
    host: 'localhost'
    port: '1025'

I'm not opposed to the form you're suggesting though, which presumably means the keys will be the action ids, though we will have do some filtering to prevent prototype pollution on them (probably?).

@mikecote
Copy link
Contributor Author

mikecote commented Apr 9, 2020

@pmuellr oh, I was thinking only JSON objects could be passed through. Didn't know what you have is what is needed to make arrays work. I will close this issue, thanks for the insight!

@pmuellr
Copy link
Member

pmuellr commented May 5, 2020

Re-opening this, as we found that the structure for these doesn't work great when you want to configure the keys in the kibana keystore; you have to reference the secrets with the index they are in the array, like so:

node src/cli_keystore add xpack.actions.preconfigured[4].secrets.password

(note, customers would use bin/kibana-keystore, but that doesn't work in dev envs, you need to use node src/cli_keystore instead)

Going to look to see how changing the structure so it's an object with action ids as they keys works out. That should allow you to do something like the following, where mySlack is the id of a pre-configured slack action:

node src/cli_keystore add xpack.actions.preconfigured.mySlack.secrets.password

@pmuellr pmuellr reopened this May 5, 2020
pmuellr added a commit to pmuellr/kibana that referenced this issue May 7, 2020
resolves elastic#63171

Previously, preconfigured actions were specified as an array of action
properties.  This ended up being problematic when using the kibana keystore
for secrets, as you'd have to reference specific actions via index.

This changes preconfigured actions to be specified as an object, where the
property key is the id, and the body is the remainder of the action properties.

As access to preconfigured actions has leaked across the code base, it's
probably time to consider changing the internal representation from an array
to a Map, to provide easier access by action id.  For a future PR.
pmuellr added a commit that referenced this issue May 7, 2020
…65397)

resolves #63171

Previously, preconfigured actions were specified as an array of action
properties.  This ended up being problematic when using the kibana keystore
for secrets, as you'd have to reference specific actions via index.

This changes preconfigured actions to be specified as an object, where the
property key is the id, and the body is the remainder of the action properties.

As access to preconfigured actions has leaked across the code base, it's
probably time to consider changing the internal representation from an array
to a Map, to provide easier access by action id.  For a future PR.
pmuellr added a commit to pmuellr/kibana that referenced this issue May 7, 2020
…lastic#65397)

resolves elastic#63171

Previously, preconfigured actions were specified as an array of action
properties.  This ended up being problematic when using the kibana keystore
for secrets, as you'd have to reference specific actions via index.

This changes preconfigured actions to be specified as an object, where the
property key is the id, and the body is the remainder of the action properties.

As access to preconfigured actions has leaked across the code base, it's
probably time to consider changing the internal representation from an array
to a Map, to provide easier access by action id.  For a future PR.
pmuellr added a commit to pmuellr/kibana that referenced this issue May 7, 2020
…lastic#65397)

resolves elastic#63171

Previously, preconfigured actions were specified as an array of action
properties.  This ended up being problematic when using the kibana keystore
for secrets, as you'd have to reference specific actions via index.

This changes preconfigured actions to be specified as an object, where the
property key is the id, and the body is the remainder of the action properties.

As access to preconfigured actions has leaked across the code base, it's
probably time to consider changing the internal representation from an array
to a Map, to provide easier access by action id.  For a future PR.
# Conflicts:
#	docs/user/alerting/action-types/email.asciidoc
#	docs/user/alerting/action-types/index.asciidoc
#	docs/user/alerting/action-types/pagerduty.asciidoc
#	docs/user/alerting/action-types/server-log.asciidoc
#	docs/user/alerting/action-types/slack.asciidoc
#	docs/user/alerting/action-types/webhook.asciidoc
#	docs/user/alerting/pre-configured-connectors.asciidoc
pmuellr added a commit that referenced this issue May 7, 2020
…65397) (#65756)

resolves #63171

Previously, preconfigured actions were specified as an array of action
properties.  This ended up being problematic when using the kibana keystore
for secrets, as you'd have to reference specific actions via index.

This changes preconfigured actions to be specified as an object, where the
property key is the id, and the body is the remainder of the action properties.

As access to preconfigured actions has leaked across the code base, it's
probably time to consider changing the internal representation from an array
to a Map, to provide easier access by action id.  For a future PR.
pmuellr added a commit that referenced this issue May 7, 2020
…65397) (#65759)

resolves #63171

Previously, preconfigured actions were specified as an array of action
properties.  This ended up being problematic when using the kibana keystore
for secrets, as you'd have to reference specific actions via index.

This changes preconfigured actions to be specified as an object, where the
property key is the id, and the body is the remainder of the action properties.

As access to preconfigured actions has leaked across the code base, it's
probably time to consider changing the internal representation from an array
to a Map, to provide easier access by action id.  For a future PR.
# Conflicts:
#	docs/user/alerting/action-types/email.asciidoc
#	docs/user/alerting/action-types/index.asciidoc
#	docs/user/alerting/action-types/pagerduty.asciidoc
#	docs/user/alerting/action-types/server-log.asciidoc
#	docs/user/alerting/action-types/slack.asciidoc
#	docs/user/alerting/action-types/webhook.asciidoc
#	docs/user/alerting/pre-configured-connectors.asciidoc
@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:Alerting 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