A brief introduction to AWS Chatbot policies that give you greater control over the chat content

AWS Chatbot was originally released in beta in July 2019 and has since had numerous features released to empower teams. The service allows DevOps and Software teams to use messaging programs to monitor and respond to events in their AWS accounts without leaving their company’s messaging tool—currently, Microsoft Teams, Slack, and Amazon Chime are supported.

Core Concepts of AWS Chatbot

As shown in the diagram below, the infrastructure and configuration are available in AWS Chatbot:

• Sources — many sources can input into AWS Chatbot via one or more SNS (simple notification service) topics
• Chatbot Channel/Destination — per channel configuration, it can target one destination (i.e., Slack Channel within a Workspace, Teams Channel within a Tenant, etc.)
• IAM Role — permissions used by the Chatbot when invoked.
• GuardRails Policy — administrators can limit what AWS services and actions can be leveraged
• Cloudwatch Logs — send Chatbot logs to Cloudwatch log groups

Not shown in the architecture is the ability to require users to configure a user-role mapping and not use the general IAM role. This is a useful feature when the messaging channel can have multiple personas, e.g., security teams, platform operators, fin-ops teams, etc.

Example Use Case

Operations teams want to gauge an alarm they’ve received without the need as quickly as possible, potentially while on the commute home—a very real-world scenario.

In this case, an alarm was received that a backup job had failed.

To gain more insight into whether this alarm is a systemic issue, we look at one of the configured dashboards showing backup jobs from the preceding days.

From this, we can see that the backups have been working successfully in previous days. Therefore, an informed decision was made that the investigation into the issue can continue tomorrow.

The above is a scenario that requires read-only permissions, AWS chatbot is able to complete actions on your behalf (if configured) — for example restarting EC2 instances, databases or invoking Lambda functions.

Introducing Chatbot Policies

Allowing users into interact with the AWS platform from an external system that has vastly different security controls brings concerns not only around external attack vectors but also user access reviews.

Chatbot policies are the latest inclusion in the AWS Organisation Policy suite, providing:

• Enforcement of the messaging platform (eg Microsoft Teams, Slack, Chime)
• Restricting access to specific workspaces
• Restricting visibility settings to public or private channels
• Set and enforce specific role settings

What Does This Enable

With the functionality being four-fold, here is what an implementation can look like:

Using an approved Messaging Platform

• Ensure teams use the approved “Microsoft Teams” workspace, adhering to the authentication/authorisation process while not allowing their data to be configured to be sent to other instances.
• Remove instances of Shadow IT where free instances of Slack are leveraged (which often are hard to identify users that “should have” been offboarded).

Configuration of access methods

• Complying with organisation requirements to not use service roles (for example, if using a general IAM role in ChatBot) by ensuring users select the appropriate roles.

AWS Chatbot has seen significant useability improvements in recent years and continues to improve team efficiencies. With the latest release, we hope to see adoption increase where enterprises can provide the relevant controls they require.