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:
I've been using #AWS for 8+ years now, so IAM is relatively second-nature to me. But I just sat down to explain it to someone new to AWS and... wow, it is a confusing service. (thread) #aws #cloud #security #cloudcomputing
— Matt Fuller (@matthewdfuller) January 2, 2020
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:
Yeah it’s quite inconsistent. For example, there are APIs in the SDKs that aren’t in the policy generator. And APIs in the policy generator that aren’t in the SDKs. pic.twitter.com/2Nd4Nr3dY7
— Aidan W Steele (@__steele) January 3, 2020
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.