Effective Actions for AWS IAM

TL;DR I made Effective IAM Actions, a small tool to expand wildcards "*"in IAM Policy Actions so that you can see explicitly what permissions are granted by a policy. It supports multiple statements in each policy, Allow and Deny effects, and summarises the granted actions by resource.

Here's a few extra details behind the why and how of the tool.

IAM is Hard

Tweets like this summarise the experience a lot of people have with AWS IAM:

While I agree with the sentiment, I'm a huge fan of IAM. It's amazing what they do as a global service that underpins every. single. request. you. make. to an AWS APIs 😱 and everything (well, nearly) is an API in AWS.

Even though I work with AWS every day, I was definitely guilty of not understanding IAM very well for a long time; there were a lot of "*" in my policies, and if I'm not careful they creep back in (sorry to my suffering teammates!).

It took a few years of working with AWS daily before I fully appreciated the importance of IAM, and getting to the point where it's relatively easy to get right (when I'm not being lazy).

glassechidna/trackiam

Over this last pre:Invent period it was fun (don't judge me!) to follow on along with the trackiam project on GitHub by Aidan Steele, seeing the new services before they were announced.

Managed Policies

Seeing updates to the myriad of AWS Managed Policies made me realise what a big role they play in many AWS-based systems; typically I have recommended the Managed Policies as a starting point for most projects, before crafting specific, least-privilege policies for systems (once the exact requirements are understood fully). I've taken this approach so that permissions will not be the cause of functionality issues in the early stages of project, slowing-down and causing developers (aka. me!) a lot of frustrations.

The reality is that even managed policies have issues sometimes and receive updates, but there is no built-in visibility to these changes. Changes and additions to the existing service actions also mean that wildcards ("*") in these policies (and your own, custom policies) can and do change meaning over time.

In an attempt to make the implicit explicit, I created the Effective IAM Actions tool to visualise the actual actions my policies were granting.

Stack

The tool is a small client-side Vue.js SPA, with Bulma for styling.

I used the Vue CLI to scaffold the project, and can't recommend it enough - everything "just worked" for me; while I have some experience with Vue, it'd been a while since I'd started a project from scratch.

I've got a CodePipeline pipeline that builds the source from GitHub in a CodeBuild container before deploying the site via the native CodePipeline-to-S3 integration. All of the site's infrastructure is in CloudFormation, obviously!

policies.js

The policy information used is generated from the policies.js used by the AWS Console.

As discussed on Twitter this list is not perfect, and there are discrepancies between this file and the SDKs:

The reality is until AWS gives us programatic access to the policies definition language, it's the best we've got.

Feedback

I've got a laundry list of improvements I'd like to do to it, but realistically I'm unlikely to get to (personally, I blame the kids):

If you've got any feature requests, find any bugs, or have cool ideas, please let me know; I'm much more likely to do something if I know it will help someone.