At Spacelift, we're using Slack for internal communication. And we know that other tech companies do the same, so we've created a first-class integration that we ourselves enjoy using.
Here are examples of messages the Spacelift application sends to Slack;
Linking your Spacelift account to the Slack workspace»
As a Spacelift and Slack admin, you can link your Spacelift account to the Slack workspace by going to the Slack section of the Settings screen.
The integration is an OAuth2 exchange which installs Slack Spacelift app in your workspace.
Once you install the Spacelift app, the account-level integration is finished and the Slack section of the Settings screen informs you that the two are talking to one another:
Installing the Slack app doesn't automatically cause Spacelift to flood your Slack channels with torrents of notifications. These are set up on a per-stack basis using Slack commands and the management uses the Slack interface.
Though before that happens, you need to allow requests coming from Slack to access Spacelift stacks.
Managing access to Stacks with policies»
Our Slack integration allows users in the Slack workspace to interact with stacks by adding the ability to change their run state or view changes that are planned or were applied.
Similar to regular requests to our HTTP APIs, requests and actions coming from Slack are subject to the policy-based access validation. If you haven't had a chance to review the policy and Spaces documentation yet, please do it now before proceeding any further - you're risking a chance of getting lost.
Currently, we allow:
- Confirming and discarding tracked runs.
- Viewing planned and actual changes.
Both of these actions require specific permissions to be configured using the login policy. Confirming or discarding runs requires Write level permissions while viewing changes requires Read level permissions. The documentation sections about policies below describe how to setup and manage these permissions.
The default login policy decision for Slack requests is to deny all access.
They allow for granular space access control using the provided policy data such as slack workspace details, Slack team information and user which interacted with the message data. Using the Login policy you can define rules which would allow to have Read or Write level permissions for certain actions.
Login policies also don't need to be attached to a specific stack in order to work but are instead evaluated during every stack mutation or read attempt from the integration.
It's important to know that if you have multiple login policies, failing to evaluate one of them or
having at least one of them result in a deny decision after the evaluation is done, will result in the
overall decision being a
Here is an example of data which the login policy receives when evaluating stack access for the integration:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50
slack object in the policy input data is built using Slack provided data. See their official documentation for always up-to-date and full explanation of the
slack object fields.
Using the above data we can write policies which only allow for a specific user or slack team to access specific spaces in which your stacks reside.
For example here is a policy which would allow anyone from a specific slack team to alter stacks in a particular space:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
Available slash commands»
It's recommended to instead use the notification policy in order to manage slack messages received from Spacelift. These slash commands are deprecated.
Three slash commands are currently available:
/spacelift subscribe $stackId- subscribes a particular Slack channel to run state changes for a given Stack - requires ;
/spacelift unsubscribe $stackId- unsubscribes a particular Slack channel from run state changes for a given Stack;
/spacelift trigger $stackId- triggers a tracked run for the specified Stack;