Developing a DevOps tool for SSO with G Suite on AWS
beSharp | 10 September 2019
How many little repetitive things do you do every day in your AWS Developer job? And how many different AWS accounts to deal with? Also, how many huge problems could spin-off from small tasks like identity and access management and credential rotation? We guess a lot because we got stuck in the same way in our early days.
What to do? We decided to develop a tiny tool that leverages G Suite Single Sign-On to securely manage programmatic (CLI/SDK) access to AWS resources distributed among several AWS accounts.
Despite being born as an internal tool, we soon decided to evolve it, to help as much as many Developers and DevOps as possible.
This is how everything has started.
In the beginning…
Back in our early days, we were just a typical start-up. We had only one AWS account, where all our projects were developed and maintained.
So, the first thing on the agenda was to provide secure access to the AWS console while maintaining ease of use for our developers (we had and still have a rigorous policy about passwords and MFA). The idea was to set up Single sign-on with G Suite, to leverage the security of our Identity Provider and access the AWS console with our Google credentials.
However, we still had some concerns about the local environment of our developers. Using IAM users to push the code and deploy our projects didn’t seem too smart… what if some credentials were stolen or accidentally pushed to a git repository and someone tampered with our account?
All these considerations led to the very first version of LookAuth, a small desktop software that automatically generates short-term credentials through Secure Access Token Service (STS) for our Developers, to enable them to perform actions in our account. Since the beginning, it leveraged the SSO with our identity provider to ease the authentication and authorization mechanism.
Moreover, it came with a nice-looking user interface!
Then the number of our customers started to grow, and we realized that using a single account to develop and maintain all of our projects was not the best option.
We wanted to isolate each customer’s resources, so we started splitting our code, workloads, and configurations into different AWS accounts. On top of that, we got more structured customers, with internal compliance policies that require to develop, maintain, and publish the projects on their AWS accounts.
We soon got a work ecosystem with multiple AWS accounts, some of which weren’t even our own, and we needed to access and perform actions into these accounts several times daily. Switching back and forth into many different accounts, even with the help of the first version of LookAuth, was not very smart.
So we took our time and refactored LookAuth to accommodate our new needs, by just letting the developers save on their workstations the accounts and roles to be assumed and select them through the UI.
The results were astonishing! We immediately cut about half an hour a day of switching into different accounts, while keeping the short-term and secure nature of the generated credentials too! Everything only by selecting the desired account from a drop-down, saving time for developers to do what they do best.
We kept increasing our numbers, and we’re still growing. The challenges we are facing now are a little bit different from the previous ones: while we always had to solve technical issues, now we are encountering more of a governance problem.
Right now, everything is more about giving the right access to the right people, with the least privileges needed to do their work. Also, we can’t expect our developers to know everything about our customers or what they are allowed or not to do in their accounts.
Again, the solution was simple. We took out from the local tool (and from the developer) the option to configure accounts and roles to assume, and we centralized it into a web-based management console.
Its particular task is to ensure that everybody can access the right customers’ accounts with the correct set of privileges, and only for the time needed to perform its specific task; now all the configurations are stored into the management console and are pushed dynamically to the desktop client.
So we are. Talking to our customers’ and attending to various AWS conferences made us realize how many people in the DevOps community shared our same needs. However, we would have never thought that this little idea of ours would become something more.
Today for us is a great day, like the ones you hope to happen more often: we are so excited to share the result of our struggle to let everyone benefit from the knowledge we built.
So, ladies and gentlemen, enjoy LookAuth!