Running your DevOps automations on Slack (i.e. SlackOps) has many advantages, but there are also additional considerations when thinking about security otherwise known as DevSecOps. This blog post will go over some things to consider when moving to a self-service Slack model for your developer workflows or automations (we call them Ops).

A good place to start is by planning out how you will run the Ops or automations over the public internet. For example, don’t publish any secret keys such as IAM Secret Access Keys to GitHub or to a public Docker Repo. Beyond that, using TLS whenever possible is essential to avoid eavesdropping.

The next consideration is how to grant access to your users while retaining control of your infrastructure. Here are some tips:

Managing User Access

  1. Don’t give Slack employees root on your infrastructure. For example, with the CTO.ai platform, you can use our hosted vault or bring your own vault so that your credentials are encrypted and can only be accessed directly by your user code.
  2. Don’t give Slack employees access to your code. Slack should be simply the client which tells a platform to run the automation in a secure way.

In CTO.ai’s architecture, for example, the user is required to associate their Slack user to their CTO.ai account using a secure authentication layer that has dependencies outside of Slack. Theoretically, if a Slack employee were to try to execute a workflow, we would be able to see that they don't have this privilege and flag or reject that request because they wouldn't have the CTO.ai associated membership.

At this point, it's just as secure as any web application or even CLI, which has better understood virtual and physical attack vectors.

Infrastructure Permissions

Make sure to control who can make changes to the infrastructure.

One idea is to set up teams so that you can control which Slack channels (private or public) they can run in to deeply control who has access to the workflow.

Even if someone has access to the workflow, they shouldn’t see the secret as if it's printed, it should be removed from the output.

Additionally, interaction with the secrets should be pushed outside of Slack (i.e. in a browser or CLI).

Backend Platform Considerations

For running any workloads using Slack, a backend computing platform is needed. Slack doesn't know what's being run, they just send a webhook and the workload needs to be executed somewhere, completely outside Slack. Slack is just a client and it doesn't really know anything about your systems or workflows.

If it is a shared computing cluster, the operators should make sure that they have applied the latest kernel patches. For example, Spectre or Meltdown patches to prevent one user from reading another user’s memory. In addition, container sandboxing technology (eg. gVisor, kata containers, seccomp) should be used to further isolate one user’s workload from another’s workload.

Same idea for networking, your container’s internal network space should be isolated from any other tenants on the system, and all traffic entering or leaving the container should be encrypted-in-flight.

Depending on the level of security required, you may care that other systems such as Intrusion Detection Systems and auditing systems are installed and in working order.

And that's it! Those are the main considerations for running your DevOps in Slack. With a little thought it's a highly secure environment to provision and run DevOps workflows quickly and collaboratively.

For more information, please see our docs which gives some details of automating Slack DevOps securely with the CTO.ai platform.