Launch HN: Abbot (YC S21) – ChatOps as a Service, inspired by GitHub's Hubot
The term "ChatOps" comes from GitHub, where the two of us worked together. GitHub was always a distributed company and early on developed a culture of doing most work via chat. Engineers automated the most repetitive processes (and some of their sense of humor, too), and that grew into a shared chat-based command line called Hubot. By typing terminal-style commands into chat, you can execute any sort of process that it makes sense for your team to automate. And because it’s in a shared chat room rather than hidden on your own machine, every time you run a task, you teach someone else how to do it.
Hubot has been wildly successful at GitHub and is amazing in action. We saw GitHub’s ops team fight off the biggest DDoS attack in history from chat using Hubot, while people were cheering along in another channel using Hubot to find appropriate hype gifs. But the effect on day-to-day work was even more amazing. Anyone could easily find out what was recently deployed, how to deploy, monitor servers, page people, you name it. New employees could see how to do all those things as soon as they joined. Since there were fun commands inside of Hubot, it was great for team building, too.
We believe more companies would benefit from working this way. When Covid hit, many companies suddenly found themselves struggling to make distributed teams work better. It is challenging to understand what everyone is doing, or even how to do regular tasks, since it's not easy to tap someone on the shoulder and ask. We decided to build Abbot to help teams adopt this style of work.
When we started, we built a list of what wasn’t fun about Hubot. Hubot required a lot of configuration, wasn’t reachable if chat was down, testing new scripts could be painful, there was no unified way to manage permissions, and so forth. We built Abbot as a hosted platform that handles all these things so developers don’t have to.
Because Abbot is a platform, we provide a unified interface for auditing, access control, data access and more. If users understand how to use a single Abbot command (or “skill” in Abbot parlance), they'll know how to use any other Abbot command. Since we built Abbot to support multiple chat systems, we made it so that all Abbot commands are cross platform – commands written for Slack will work in Discord, and so forth. You can write commands in C#, Python, or JavaScript (we will support more languages in the future). We also do a lot of things Hubot does not, like allowing users to control access to the execution of their commands from inside of chat, or exposing an API endpoint for every command so that they can react to the outside world. There’s nothing to fork or configure – you can get started in two clicks from our website.
Abbot has a Package Directory where people can share the commands they’ve written. There are a few dozen packages in the directory today, with more being added every week. Packages are MIT licensed and installable in one click. Because it's so easy to create new commands, teams tend to create a lot of small ones that accomplish a single task. For example, we have a `tweet` command that allows us to use chat as our communal Twitter client (available in the Package Directory at https://ab.bot/packages/aseriousbiz/tweet).
Today, people use Abbot to deploy Git branches to staging environments, track daily standups, figure out time zones for all their teammates, give each other internet high-fives (well, sparkle points), and even open their office door. We are focused on DevOps and...
36 comments
[ 3.5 ms ] story [ 64.8 ms ] threadCan I use Abbot along with Terraform on ECS? Would love to setup some deploy scripts
For example, we have an existing package that uses the GitHub deploy API to deploy software https://ab.bot/packages/aseriousbiz/deploy
If you trigger your deploys using GitHub's API, then you could just use that skill. Otherwise, you can copy that skill's code and adapt it to your needs. Hope that helps!
(In case it's not clear, I'm the "Phil" in the post) :)
That is, when is chat-initiated typically a better fit than something initiated by a check-in, build, incident detection, and so on?
(Not knocking it, just curious)
Chat is also a great environment for getting notifications about extraordinary events. We get notifications in chat if a link on our homepage is 404ing, whenever deploys happen, or as scheduled updates for things we want to pay attention to but don't want to manage a separate website to handle them.
We usually start with small commands and then grow them to automate more of the "well trodden path" as we understand what we want to automate. Because every command (we call them skills) can expose an API, it's possible for an Abbot skill to respond without any person being involved.
A big benefit is that you don't have to share credentials from the Twitter account, but still make it available to people in your company.
Is there a way to have commands that are approved by another person (for example, `@abbot deploy skip-tests` that has to be approved by another team member with a thumbs up reaction or a reply?)
Is there a way to add replies to the original message from the bot directly? Or at least respond to the same channel? (like: I trigger a deploy, and the bot sends a message to the slack channel when the deploy is done)
In that case, when someone runs `@abbot deploy skip-tests`, you'd present a message with a button. You'd have to validate the user that clicks the button yourself.
Abbot does have support for ACLs on skills, but it's for the whole skill. It doesn't yet support restrictions on actions within a skill.
Let me know if you attempt this and run into problems. I'm happy to review code! :)
Can you explain what dedicated skill runner means? saw it on the plans page, but couldn’t find (or missed? on mobile now) what it is and why it costs extra…
Right now all skills run through the same infrastructure. We are figuring out our package management story currently, but today everyone has the same packages loaded, and all requests come from our shared infra. Some companies we talked to have specific library needs (especially internal libraries) or requests for dedicated IPs for their runners. For most teams, this probably isn't needed. We spend a lot of time making sure things are fast and scale, so it's mostly about control for our customers.
I still think Hubot (and bots in general, a la GitHub's internal usage) is severely undervalued. GitHub's usage of internal chat was pretty groundbreaking, which I think led to the movement behind Slack's growth. But there was a missing point in the rise of chat- namely, scripting automated processes and debugging collaboratively in public (internally). Which makes sense, since Hubot was a pain to set up and build a company around. So yeah, really excited about Abbot to jump in that hole in the market.
We also wrote a blog post about how we think about our problem space and value proposition recently: https://blog.ab.bot/archive/2021/07/15/tools-for-inside-the-....
Not quite as succinct as a video, but it might help paint a a more vibrant picture of how we see the world.
From my end, I think these are solvable but may require thinking about the problem differently. How are you thinking about security?
For our threat model, we focus on _companies_ using Slack, Discord, and Teams, though our efforts apply to communities, etc. For the sake of this question, I'll focus on companies using Slack, but most of it applies to the others.
Even without Abbot, if someone gains access to an employee Slack account, they can do immense damage. So it's very important for companies to enforce good security on Slack such as 2-factor auth, etc. If you use Abbot, that's even more important. To interact with Abbot in chat, a user must be logged into your Slack organization. So we encourage customers to take their Slack account security seriously.
Now it may happen that a Slack account is compromised despite a company's best efforts. So the next level of protection is the ability to protect skills using Abbot's access control. You can restrict skills to a limited set of users. That makes it possible to follow the principle of least privilege and reduce exposure of the most sensitive skills.
Finally, despite our best efforts, there may be the case where someone gains access to a privileged account. Abbot logs every interaction it has with users, whether through the Bot console (in the website) or via chat. So if someone does somehow get access, you can audit what activities they took, what secrets they accessed.
It's also important to look at security from the perspective of a skill author. To create a skill, a user has to be a member of the "Members" role in https://ab.bot/. This requires that they are a member of the associated Slack organization and have logged into https://ab.bot/ with their Slack account (we don't implement our own authentication).
An Abbot Administrator can choose to let anyone in the Slack organization automatically be added to the "Members" role when they log in. That may be appropriate for smaller high-trust companies. For larger companies, administrators may want have tighter control on access to the website.
Skill authors are encouraged not to embed tokens and other secrets in the code for skills. Instead, use the secrets management built in. There's also a proxy link feature for certain cases where a secret is embedded in a URL and you don't want the secret exposed even to skill authors.
That's where we are today.
In the future, we'd like to integrate with Active Directory, LDAP, etc. for managing access to the site and skills. Also, we know that many systems people want to access are going to be behind a firewall. So we are looking into onprem options, but those may be further down the road.
If you have some ideas on where we can improve or areas we should be thinking about, we are definitely interested in hearing about it. This is very important to us.
Additionally companies forced to be SOX compliant require separation of duties, which is often incompatible with slash commands that impact production or revenue generating infrastructure.
SOX compliance is a bit outside of our domain of influence; our goal is to give people the most powerful tools we can, in a way that they can run it in their environment without having to reinvent the wheel.
On reread, I realize that I'm not sure I understand what sort of attack you're talking about. While I think we've done a good job of making Abbot a safe entity, could you describe how this works? It's possible there's an attack vector we haven't considered. Thanks for sharing!
The most common reflection attack is through support systems, specifics will vary depending on the product used. Not all are vulnerable to this.
Open a support ticket with support@company.com pretending to have a valid complaint. Obtain the unique e-mail address for your ticket such as support+2392@company.com, and use "Sign up" at https://company.slack.com/signup#/domain-signup with the support ticket e-mail address.
The support ticket system can leak the contents of the Slack invitation as a ticket update. Once you know the validation URL Slack allows you to sign up.