Thank you for your interest in AccessBot. While we appreciate the positive feedback it has received, we have decided to discontinue development and support for AccessBot in favor of focusing on our core product offerings.
AccessBot has been superseded by "Integration for Slack," included within the StrongDM Enterprise Bundle and paired with the "Access Workflows" feature. This integration provides similar functionality to AccessBot, allowing users to easily manage access requests and approvals directly within Slack.
- Latest release of AccessBot v2.0.79 will continue to function as long as the Slack API has no changes, but no further development or bug fixes will be implemented.
- No further Support will be provided for accessbot issues. Troubleshooting page linked below can be of help.
- We recommend transitioning to the "Integration for Slack" as your primary tool for managing access requests.
- If you have any questions or concerns about this transition, please don't hesitate to contact us.
We're excited about the possibilities that "Integration for Slack" and "Access Workflows" offer, and we believe they represent a significant improvement over AccessBot. We hope you'll explore these features and see how they can benefit your organization.
- StrongDM Enterprise Bundle: https://www.strongdm.com/pricing/
- Access Workflows: https://www.strongdm.com/docs/admin/workflows/
- Integration for Slack: https://www.strongdm.com/docs/admin/workflows/slack/
- Accessbot troubleshooting: https://strongdm.github.io/accessbot/docs/TROUBLESHOOTING.html
Sincerely,
The StrongDM Team
The Slack Classic implementation has been deprecated. In case you're still using it, please migrate ASAP to the Slack Bolt implementation.*
AccessBot is a chatbot that manages access to strongDM (SDM) resources through temporary grants. Some main features are: you can have a manual approval flow and an automated one for specific resources (or all of them if you want); you can configure specific approvers for specific resources; you can configure what resources can be requested, or hide specific ones; the users can specify the duration of the temporary grants and even the reason behind it. The resources can also be accessed by role grants, which means that the user can request access to a role, and they will have temporary access to all resources from that role.
AccessBot can be installed on Slack or MS Teams.
A curated version of the documentation can be found here.
You can also watch our demo video of AccessBot on YouTube.
In order to deploy AccessBot, first you need to define the following required environment variables:
- SDM_BOT_PLATFORM. The platform that the bot will be installed on, i.e. "ms-teams", "slack" or blank (which will be interpreted as Slack by default)
- SDM_ADMINS. List of admin users who will manage the bot and approve grant requests (by default).
- For Slack platform: use the
username(not Display Name) of each admin, e.g.@user1 @user2(See this section for more.) - For MS Teams platform: use the email addresses of all the admins
- For Slack platform: use the
- SDM_API_ACCESS_KEY. SDM API Access Key
- SDM_API_SECRET_KEY. SDM API Access Key Secret
For Slack platform, you need to provide the following required variables:
- SLACK_APP_TOKEN. Slack App-Level Token
- SLACK_BOT_TOKEN. Slack Bot User OAuth Token
For MS Teams platform, you need to provide the following required variables:
- AZURE_APP_ID. Azure Bot application ID
- AZURE_APP_PASSWORD. Azure Bot application password
- AZURE_AD_TENANT_ID_. Azure Active Directory Tenant ID
For a full list of configuration variables please read: Configure AccessBot
Detailed instructions about how to configure SDM and a platform (Slack, Slack Classic or MS Teams) for AccessBot can be found here:
AccessBot is available as a Docker image. For deploying it we recommend you to use a container orchestrator, e.g. Kubernetes. Here's a k8s deployment descriptor that you can use as a reference. You can also use Helm to deploy AccessBot, learn more.
Most customers deploy AccessBot as a k8s deployment of one replica using the bot's healthcheck endpoint, so the Orchestrator ensures that there's always an instance of the bot available. At the moment, the bot doesn't support load balancing nor slack webhooks.
Refer to this docs to learn more about the AccessBot deployment infrastructure.
If you're using technologies that dispose containers, e.g. Fargate, and manual approvals, you should enable state handling via SDM_ENABLE_BOT_STATE_HANDLING to persist manual grant requests. Please refer to the documentation for more details of this variable.
To make the persistency work in this scenario, you need to mount a folder pointing to the path /errbot/data/grant_requests inside the container. This folder will store the grant requests state, persisting the data while the containers are disposed and redeployed.
If you decide to deploy on Fargate and need some help, please refer to the Fargate deployment docs.
For starting the bot with docker compose. Enter all required variables in the docker-compose.yaml file and execute:
docker compose build --no-cache
docker compose up -d
Then, the bot should start running in the background. If you want to check the logs you can run the following command:
$ docker logs accessbot_accessbot_1If you want to install and execute the bot locally without Docker, please refer to: Configure Local Environment If you want to expose a Prometheus endpoint with AccessBot Metrics, please refer to Configure Monitoring
Once AccessBot is up and running, you can add it as an app or to a channel and start using it!
First, check the bot and Slack interconnectivity state:
You would expect to see no error in your logs and the messages Yes I am alive and plugin available.
If that's the case, enter any of the following commands:
help. Show available commandsshow available resources [--filter expression]. Show available resources - all or a filtered subset. Filters are optional. Please refer to the following doc for getting the list of available filters.access to resource-name [--reason text] [--duration duration]. Grant temporary access to a resource. Reason and Duration are optional.show available roles. Show all available roles*access to resource-name. Grant temporary access to all resources assigned to a role
NOTE: All AccessBot commands are case-insensitive.
For example:
Here are some of the most used variables:
- Set
SDM_AUTO_APPROVE_ALL=trueto disable approval entirely. - Use the strongDM CLI or SDK to add the following tags to individual resources:
SDM_AUTO_APPROVE_TAG=auto-approve-- automatic approval for this resourceSDM_ALLOW_RESOURCE_TAG=allow-resource-- resource is displayed viashowcommand; any access request auto-fails if the resource does not have the tagSDM_HIDE_RESOURCE_TAG=hide-resource-- resource is not displayed viashowcommand; any access request auto-fails
- Use the strongDM CLI or SDK to add the following tags to individual roles:
SDM_AUTO_APPROVE_ROLE_TAG=auto-approve-- automatic approval for this roleSDM_ALLOW_ROLE_TAG=allow-role-- role is displayed viashowcommand; any access request auto-fails if the role does not have the tag
For more information and a full list of variables, please refer to the detailed guide for access configuration.
A list of typical issues and resolutions can be found here.
In case you want to contribute to the project, please check our guidelines.
In case you need support, please check our Frequently Asked Questions and support documents.