At Sparkbox, our pursuit of console convenience has led us down a few different paths. In the past, a simple shared username and password was enough. As we grew and both gained and lost people, it became evident that sharing credentials was always a risky strategy and that we needed a change. Over the last few years, we’ve deployed one tool to help with this, began development of another tool, and are now considering other more flexible options. I don’t think this situation is uncommon, either. Perhaps you share passwords today, or are currently struggling through half-working measures to end the practice. I want to walk through what we’ve tried, explain our experience along the way, and then leave you with where I think we should be headed next.
The Simplest Thing That Could Possibly Work
We had to stop sharing passwords, so I wrote Forte. It is a Ruby command-line app that clones a Git repository full of public key files and concatenates them into one large file. The file it produces is what an OpenSSH server expects when checking to see if a user is allowed to access a given account. Every key in this file is a separate credential for a different person to a single shared user account. This was a huge first step for us because it let us keep all those shared accounts across all our servers (along with their permissions, crontabs, etc) without sharing any more passwords. With only a small number of servers to manage, redistributing this file was an easy task for any staffing change.
I started to realize the inadequacy of Forte after we deployed our second and third internal testing servers. We had been running fewer than 10 servers for our testing and client production servers. That number would triple over the next few years, and the task of updating those keys quickly became a rather daunting chore. Far be it from me to complain though, a large number of servers meant we were serving a growing number of clients and the projects were more complex. More projects meant more people who all needed to be added to the file as they joined the team. As this process aged, it gave rise to changes to existing keys too. Not only was the size of the task growing, the frequency with which it needed to be done was increasing. I began looking for ways to automate more of this process.
An Ambitious Second Step
I wanted to migrate the features of our existing tool into a GUI, with the goal of making this task accessible to more people. Several members of our team had experimented with building native apps with Electron, so I figured I’d be next. I started on Forte GUI to eliminate the need to be familiar with command-line tools and to remove the Ruby dependency (since not everyone on the team uses Ruby). As a bonus, I’d use the opportunity to dive deeper into React and Redux. In the end, I learned much about React and Redux, clarified many of my goals around automating our public key management, but did not complete the app. I had strayed too far from the simplicity that made our original tool so successful for us.
The Right Tool
While building the Forte GUI, Sparkbox was also working on being more intentional about managing our servers in general. I had heard about tools like Chef and Ansible before but hadn’t spent any time with them. When I learned that one of these tools would be used on a client project, I decided to do some digging. I immediately stumbled upon an Ansible module for managing public keys. Similar to Forte, it adds public keys to the authorized_keys file for a given user account on a server. Even better, it can obtain those keys from your Github account, eliminating our dependency on manually maintaining a repository of our current keys. It clicked right away that I was solving the wrong problem. Our public keys are but one part of the larger responsibility of taking care of our servers. Any task that needs to be performed on one server will need to be done on most (if not all) of them. Forte would never get me closer to any of those.
That’s where we stand today. Will Ansible be the right tool? I don’t know yet. This will be a topic we will write more about in the future once we know more. The potential of Ansible is exciting, but the lessons learned from Forte tell me to work in smaller chunks. What I do know is that, like in the beginning, we’ll start with the simplest thing that could possibly work.
