The Nautobot ChatOps plugin just recently received a new feature for Slack that has been requested for a long time. If you are using Nautobot ChatOps plugin v1.10.0 or greater with Slack, you now have the ability to use Slack’s socket mode for connecting compared to their traditional webhook method!

In this blog post, we will dive into what exactly this means, how you can leverage socket mode, and why you may want to use it over the current method of connecting. Let’s dive in!

How Does ChatOps Connect Today?

Nautobot ChatOps today currently supports four major platforms: Slack, Microsoft Teams, Webex, and Mattermost. All four of these platforms support incoming webhooks, so this is the default setup method for them.

Let’s take a look at how this traffic flow currently works using this diagram from the official documentation page.

1. When a user sends a message to the bot via the client application (phone or desktop app), the connection is initiated from the client, and the message gets sent to Slack’s cloud servers.
2. The Slack servers then initiate a connection to the ChatOps plugin running on the Nautobot server/container.
3. Since this is a new incoming connection, it must be port forwarded and allowed through any firewalls in your network between the internet and your Nautobot server.
4. Since your externally facing firewall is stateful, Nautobot then replies back to Slack using the established TCP session.
5. Slack then returns the response to the client.

The important step to notice here is step 3. In order for Slack’s web services to communicate to Nautobot with the request originating from the user/client, traffic must be explicitly allowed inbound. Normally this wouldn’t be much of an issue on a firewall. However, the issue is made more complicated for three reasons:

1. A port must be opened and forwarded from the public internet to your Nautobot appliciation.
2. It is not viable to simply white-list Slack’s IP addresses as the API requests originate from within AWS, so the IP ranges are quite extensive and will encompass other services on AWS besides Slack (aka the rest of the internet).
3. Slack requires a valid Third-Party SSL Certificate before it will make the connection.

There are a few ways to secure inbound ChatOps access from Slack, such as adding verification that the webhook is legitimate, using an externally facing API Gateway, etc. One example Nautobot currently uses is verifying all inbound requests from Slack using a signed secret.

While we won’t get into all of them here, you can read about some of them in Slack’s documentation “Best practices for security”.

In the end, this still requires enabling inbound access from the public internet to your internal Nautobot instance, which tends to make InfoSec a little nervous.

Introducing socket mode.

What Is Socket Mode?

Socket mode allows traffic to no longer originate from Slack on the public internet, but instead from internally going out.

1. The Nautobot server initiates and maintains a connection to the Slack cloud servers. Because the traffic originates from inside the network, externally facing firewalls do not need to allow inbound traffic from Slack to the Nautobot server. They only need to allow traffic outbound from the Nautobot server to Slack on the internet. This connection remains open through this entire process.
2. A user will send a message via their desktop/mobile Slack client to the Nautobot ChatOps bot.
3. Slack forwards the message to Nautobot over the existing WebSocket connection.
4. Nautobot then replies over the existing WebSocket connection to Slack.
5. Slack forwards the response to the client.

This reduces the externally facing Nautobot footprint out to the internet and does not require opening specific inbound access to Nautobot from the internet just to get ChatOps working.

Additionally, once Nautobot establishes a connection to Slack it keeps the connection active, eliminating the need to reestablish a new connection each time (as with webhooks).

Should I Use Socket Mode?

Either setup option works for Nautobot ChatOps with Slack. However, with the number of customers we’ve worked with at NTC that express concern over exposing Nautobot to the public internet and do not have an API gateway they can leverage to lock down inbound access, we expect to see many users prefer to use socket mode for security and compliance reasons.

If you currently have Nautobot ChatOps working with Slack, there is no real need to move over to socket mode. However, if you are setting it up new for the first time and your InfoSec team has concerns with enabling inbound access, socket mode may work better for your situation.

Setup Instructions

Support for socket mode with Slack was added to Nautobot v1.10.0, so if you are on an older version you will need to upgrade your Nautobot ChatOps plugin first. Since this plugin acts independently from other Nautobot ChatOps extensions (e.g., Meraki ChatOps, Ansible ChatOps, etc.), configuring this base plugin for socket mode will enable these other plugin extensions to leverage it as well without needing to specifically upgrade them (provided no other dependency conflicts exist).

Instructions for setting up Nautobot ChatOps for Slack can be found here. Note that the Nautobot application requires an additional management command to be run at startup time, nautobot-server start_slack_socket, which can be added as a systemd service so it automatically runs each time the app is restarted. Details can be found in section “Startup Slack Sockets”.

There is also an additional credential slack_app_token needing to be added to the Nautobot ChatOps plugin config section in nautobot_config.py. Details for this are found in section “Post App-Creation Steps” in the install docs as well.

Note: While socket mode support is only added to the Slack platform so far, we are working on adding in support for socket mode with the other providers (where supported) in the future.