In this series, we present AWS tooling from the community for the community. We talk directly with the tool makers. Who are they? What problem does the tool solve? And what motivates them to contribute to open-source AWS tooling.

This time, we talk with Scott Piper about Parliament. You can connect with Scott on Twitter or LinkedIn.

cloudonaut: Tell us a little about yourself, your history with AWS, and your motivation to develop AWS tooling.

Scott Piper: My history with AWS didn’t really start until a little over three years ago, when I released flaws.cloud, which is a free CTF of sorts, that I built to teach myself and the DevOps folks at the company I was with, about AWS security. I released it publicly and thought that if I got lucky, maybe a dozen people would check it out. Instead, in the first month 30,000 people tried it out and it has continued to be a popular site for learning about AWS security in a hands-on way. And it continues to be relevant! One of the levels (again, this was created three years ago) is nearly the exact same as the scenario that resulted in the Capital One breach a few months ago.

As a result of the popularity of flaws.cloud and some other things, I decided to start a consulting business focused on AWS security. I was lucky enough to be able to work with Duo Security with whom I developed CloudMapper, CloudTracker, Parliament, and some other things.

The tools I’ve developed have largely been the result of working with clients and identifying problems they had for which there weren’t any existing solutions for. Recently, I shifted my business to focusing on providing AWS security training privately to companies, but I’ll continue building tools as a result of conversations with these companies and as a great way for me personally to learn and stay on the leading edge of AWS security.

cloudonaut: What problem does your tool solve?

Scott Piper: Parliament is a linter for AWS IAM policy policies. What this means is that the JSON document you write to define the privileges and access someone has on AWS can have spelling mistakes and other problems in it, but will still be valid (ie. it will still save), so a tool was needed to check for these problems.

I had started monitoring the changes that AWS was making to their managed IAM policies and noticed that every once in a while they would make a correction to what had been a mistake in a policy. For example, a common problem was using “s3:ListBuckets” (which is the name of an API) instead of the correct name for the privilege “s3:ListAllMyBuckets”. I then manually reviewed every single AWS managed IAM policy by hand to try to find every possible mistake they had made. I found a lot of mistakes (and missed a lot as I later realized), and reported those in.

I figured there were a couple of common types of mistakes that even AWS was making so customers had to be making even more mistakes, and I should build a tool to find these. Since then, the tool has continued to evolve from finding what are basically spelling mistakes to looking for privilege escalations and the ability to create custom auditors to identify concerns that are specific to a customer’s environment, such as which policies grant access to a specific sensitive bucket.

cloudonaut: Who should use your tool? Who should not?

Scott Piper: Anyone using AWS who wants to review their IAM policies should use this tool. Parliament exists as a stand-alone tool and also as a library. If you build a tool that does any sort of auditing and checking of AWS, or anything related to IAM, you should integrate Parliament into it.

cloudonaut: Show us a short demo of your tool

Scott Piper: As a simple example, create a file with the following IAM policy:

{

"Version" : "2012-10-17" ,

"Statement" : {

"Effect" : "Allow" ,

"Action" : "s3:GetObject" ,

"Resource" : "arn:aws:s3:::mybucket"

}

}



Pass this to Parliament, and you’ll get the following output: