Kapacitor: is there a way to override the default slack url?

[findneville]

I have been going through this documentation for alerting to Slack https://docs.influxdata.com/kapacitor/v1.3/nodes/alert_node/#slack

Currently it works since there is only channel to notify. But we just got a requirement to notify a different channel that we do not know and has a different webhook URL

I know it is possible to override the channel option for slack but is there a way to override the default slack url? I tried plugging in url in the options without much success.

Any help appreciated

[bayendor]

I have raised this same problem with Influx Enterprise support. We need to be able to replicate the same kapacitor script alerting solution we had with HipChat where:

.hipChat() 
.room('room_value') 
.token('token_value')

could be added for alerts that needed to go to different channels.

And would look like this for Slack, e.g.

node.slack() 
.channel(value string) 
.url(value string)

[rbetts]

@ebb-tide Can you help us understand what the chronograf impact would be for this feature? Is this something related to the work you are doing currently?

[ebb-tide]

@rbetts- currently the slack webhook url can only be specified in the kapacitor configuration- and individual alerts in tickscript can override only the channel, username and emoji fields for a slack alert. If webhook url was changed into a tickscript overridable field, it would definitely improve the flexibility of slack alerts. The work I'm doing now is completely adaptable to this- I would simply need to whitelist webhook url as one of the fields that can be sent to the backend to construct the tickscript. One thing concerns me though- sending sensitive information like webhook url in plaintext as a post req and storing it in plaintext in the tickscript, might be a security concern? I know that Nathaniel has thoughts on this too. There are other instances (Alerta token for example, among others) in which we allow this, but I'd like to discuss.

[nathanielc]

There are other instances (Alerta token for example, among others) in which we allow this, but I'd like to discuss.

I consider it a bug that the Alerta integration supports this, but its a bug we can't fix for backwards incompatible reasons.

In general the TICKscripts should not be allowed to contain sensitive credentials. All credentials should exist in the configuration. The configuration APIs provides a safe way to modify the credentials without exposing them to end users.

A question: Its my understanding that (independent of Kapacitor) a Slack webhook URL has a configured default channel but that it can be overridden to talk to other channels on the fly, is that not the case? Or said another way what is the use case for having multiple slack webhook URLs?

If we do need to have multiple slack webhook URLs, then the solution is to expand the configuration to allow for multiple named [[slack]] sections. (This can be done in a backwards compatible way). The new config will allow each slack config section to have its own URL and then it can be referenced in the TICKscript/handlers by name. This is how we solved similar issues in the past.

[ebb-tide]

a Slack webhook URL has a configured default channel but that it can be overridden to talk to other channels on the fly

Yes- it is possible to use a webhook url which points to a channel and override the channel in the tickscript. I think @bayendor's use case is addressed by this, it would be nice to get a confirmation. But @findneville's issue sounds like they are trying to send the alert to another webhook url- perhaps another organization entirely, and not just another channel. We need to decide if we want to support this. It would be slightly more difficult for chronograf to support configuration expansions, but it could be done if that's what we decide to do.

[russorat]

Not sure if this is the use case here, but a previous company I worked at
created separate public slack workspaces for working directly with
customers or contractors that they don't want to have access to their
internal chats. For example, company.slack.com is the internal workspace
while company-contractorcompany.slack.com is the one for contractors. They
could then invite the company employees that were working with the
contractors to that new workspace.

[bayendor]

@ebb-tide Overriding the default channel for a webhook url would be fine, it it works as expected, but that wasn't my understanding. Our goal is to be able to have slack alert to different channels within the same organization.

I will try it out on one of my test instances and update the results here, but that may be something that is outside our control (Oracle locks down our Slack service pretty tightly, e.g. no web-bots, no global api tokens, etc.).

@nathanielc Regarding exposing credentials in tick scripts, that seems to be the behavior to send HipChat alerts to different rooms than the one configured globally, and one we used extensively prior to switching to Slack. We used this as the guide: https://docs.influxdata.com/kapacitor/v1.3/guides/event-handler-setup/#tickscript-syntax

[bayendor]

I can confirm on our Slack service we are able to use a webhook defined for one public channel to send messages to any other __public__ channel. Example:

// Sends an alert to the default channel defined in kapacitor.conf
|alert
    slack()

or

// Uses the global webhook defined in kapacitor.conf
// to send an alert to a public channel other than the default
|alert
    slack()
    channel('#foo')

This works for us for now. Private channels are a minor issue, that is not high priority at this point. I can provide more insight if needed.

[jamischarles]

@nathanielc

a Slack webhook URL has a configured default channel but that it can be overridden to talk to other channels on the fly

Enterprise slack may have a different restriction here. When I create my incoming webhook, I am forced to specify the channel. So for me 1 slack url = 1 channel. Being able to override the url in the tick script would allow me to use more than 1 slack channel for alerts (hugely more valuable obviously).

[jamischarles]

Being able to pass ENV vars into the tick script may help with the privacy concerns.

Update: Just read this

If we do need to have multiple slack webhook URLs, then the solution is to expand the configuration to allow for multiple named [[slack]] sections. (This can be done in a backwards compatible way). The new config will allow each slack config section to have its own URL and then it can be referenced in the TICKscript/handlers by name. This is how we solved similar issues in the past.

Is this something that works now, or are you talking future implementation?

[nathanielc]

Closed by #1833 This change allows you to have multiple slack configuration sections in the configuration. This way you can reference which slack configuration/url you want