An engine that reads messages from Slack and can act on them
New in version 2016.3.0.
slackclient Python module
Important
This engine requires a bot user. To create a bot user, first go to the
Custom Integrations page in your Slack Workspace. Copy and paste the
following URL, and replace myworkspace
with the proper value for your
workspace:
https://myworkspace.slack.com/apps/manage/custom-integrations
Next, click on the Bots
integration and request installation. Once
approved by an admin, you will be able to proceed with adding the bot user.
Once the bot user has been added, you can configure it by adding an avatar,
setting the display name, etc. You will also at this time have access to
your API token, which will be needed to configure this engine.
Finally, add this bot user to a channel by switching to the channel and
using /invite @mybotuser
. Keep in mind that this engine will process
messages from each channel in which the bot is a member, so it is
recommended to narrowly define the commands which can be executed, and the
Slack users which are allowed to run commands.
This engine has two boolean configuration parameters that toggle specific
features (both default to False
):
control
- If set to True
, then any message which starts with the
trigger string (which defaults to !
and can be overridden by setting the
trigger
option in the engine configuration) will be interpreted as a
Salt CLI command and the engine will attempt to run it. The permissions
defined in the various groups
will determine if the Slack user is
allowed to run the command. The targets
and default_target
options
can be used to set targets for a given command, but the engine can also read
the following two keyword arguments:
target
- The target expression to use for the command
tgt_type
- The match type, can be one of glob
, list
,
pcre
, grain
, grain_pcre
, pillar
, nodegroup
, range
,
ipcidr
, or compound
. The default value is glob
.
Here are a few examples:
!test.ping target=*
!state.apply foo target=os:CentOS tgt_type=grain
!pkg.version mypkg target=role:database tgt_type=pillar
fire_all
- If set to True
, all messages which are not prefixed with
the trigger string will fired as events onto Salt's ref:event bus
<event-system>. The tag for these veents will be prefixed with the string
specified by the tag
config option (default: salt/engines/slack
).
The groups_pillar_name
config option can be used to pull group
configuration from the specified pillar key.
Note
In order to use groups_pillar_name
, the engine must be running as a
minion running on the master, so that the Caller
client can be used to
retrieve that minions pillar data, because the master process does not have
pillar data.
Changed in version 2017.7.0: Access control group support added
This example uses a single group called default
. In addition, other groups
are being loaded from pillar data. The group names do not have any
significance, it is the users and commands defined within them that are used to
determine whether the Slack user has permission to run the desired command.
engines:
- slack:
token: 'xoxb-xxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxx'
control: True
fire_all: False
groups_pillar_name: 'slack_engine:groups_pillar'
groups:
default:
users:
- '*'
commands:
- test.ping
- cmd.run
- list_jobs
- list_commands
aliases:
list_jobs:
cmd: jobs.list_jobs
list_commands:
cmd: 'pillar.get salt:engines:slack:valid_commands target=saltmaster tgt_type=list'
default_target:
target: saltmaster
tgt_type: glob
targets:
test.ping:
target: '*'
tgt_type: glob
cmd.run:
target: saltmaster
tgt_type: list
This example shows multiple groups applying to different users, with all users
having access to run test.ping. Keep in mind that when using *
, the value
must be quoted, or else PyYAML will fail to load the configuration.
engines:
- slack:
groups_pillar: slack_engine_pillar
token: 'xoxb-xxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxx'
control: True
fire_all: True
tag: salt/engines/slack
groups_pillar_name: 'slack_engine:groups_pillar'
groups:
default:
users:
- '*'
commands:
- test.ping
aliases:
list_jobs:
cmd: jobs.list_jobs
list_commands:
cmd: 'pillar.get salt:engines:slack:valid_commands target=saltmaster tgt_type=list'
gods:
users:
- garethgreenaway
commands:
- '*'
Break out the permissions into the following:
Check whether a user is in any group, including whether a group has the '*' membership
On a successful permitting match, returns 2-element tuple that contains the name of the group that successfully matched, and a dictionary containing the configuration of the group so it can be referenced.
On failure it returns an empty tuple
cmdline_str is the string of the command line trigger_string is the trigger string, to be removed
Returns a tuple of (target, cmdline,) for the response
Raises IndexError if a user can't be looked up from all_slack_users
Returns (False, False) if the user doesn't have permission
These are returned together because the commandline and the targeting interact with the group config (specifically aliases and targeting configuration) so taking care of them together works out.
The cmdline that is returned is the actual list that should be processed by salt, and not the alias.
This replaces a function in main called 'fire'
It fires an event into the salt bus.
Print out YAML using the block mode
slack_token = string trigger_string = string input_valid_users = set input_valid_commands = set
When the trigger_string prefixes the message text, yields a dictionary of:
{
'message_data': m_data,
'cmdline': cmdline_list, # this is a list
'channel': channel,
'user': m_data['user'],
'slack_client': sc
}
else yields {'message_data': m_data} and the caller can handle that
When encountering an error (e.g. invalid message), yields {}, the caller can proceed to the next message
When the websocket being read from has given up all its messages, yields {'done': True} to indicate that the caller has read all of the relevant data for now, and should continue its own processing and check back for more data later.
This relies on the caller sleeping between checks, otherwise this could flood
get info from groups in config, and from the named pillar
todo: add specification for the minion to use to recover pillar
Given a list of job_ids, return a dictionary of those job_ids that have completed and their results.
Query the salt event bus via the jobs runner. jobs.list_job will show a job in progress, jobs.lookup_jid will return a job that has completed.
returns a dictionary of job id: result
Get all channel names from Slack
Get all users from Slack
When we are permitted to run a command on a target, look to see what the default targeting is for that group, and for that specific command (if provided).
It's possible for None or False to be the result of either, which means that it's expected that the caller provide a specific target.
If no configured target is provided, the command line will be parsed for target=foo and tgt_type=bar
Test for this:
h = {'aliases': {}, 'commands': {'cmd.run', 'pillar.get'},
'default_target': {'target': '*', 'tgt_type': 'glob'},
'targets': {'pillar.get': {'target': 'you_momma', 'tgt_type': 'list'}},
'users': {'dmangot', 'jmickle', 'pcn'}}
f = {'aliases': {}, 'commands': {'cmd.run', 'pillar.get'},
'default_target': {}, 'targets': {},'users': {'dmangot', 'jmickle', 'pcn'}}
g = {'aliases': {}, 'commands': {'cmd.run', 'pillar.get'},
'default_target': {'target': '*', 'tgt_type': 'glob'},
'targets': {}, 'users': {'dmangot', 'jmickle', 'pcn'}}
Run each of them through get_configured_target(('foo', f), 'pillar.get')
and confirm a valid target
Raises ValueError if a value doesn't work out, and TypeError if this isn't a message type
cmdline: list
returns tuple of: args (list), kwargs (dict)
Pull any pending messages from the message_generator, sending each one to either the event bus, the command_async or both, depending on the values of fire_all and command
Listen to slack events and forward them to salt, new version