With more than 400 million operations per second AWS IAM usage is on a scale that is often hard to comprehend. Combine that with AWS still maintaining its majority share of the cloud market, it's fair to say a good chunk of the internet is regulated by IAM roles and policies.
With that being the case you can be confident that AWS has a depth of expertise and wisdom backing up IAM. But it doesn't make managing IAM roles less of an arduous task. Often it means spending your time scrolling through multiple lines of JSON entries, which isn't exactly the most efficient way to look at permissions.
The problem is only made worse in large organisations with several accounts and multiple services. It can be uphill battle to keep track of all the permissions assigned to different IAM roles. Making assigning the correct permissions a challenge if you don't know your resources and services like the back of your hand. While also making retrospective tasks such as auditing time consuming as you struggle to get the context you need to make important decisions.
There are a number of different reasons why you’d need to audit IAM roles. As part of a new project to ensure that no unused roles haven’t been created and forgotten. As part of compliance, ensuring you meet regulatory requirements. Or even as part of a security or cost review. Ensuring that unused roles are cleaned up and users have the appropriate level of access is vital and can also help ensure users are held responsible for their actions.
To do this you can check the last time each role made a request to AWS and use this information to determine whether the team is using the role. You want to gather more information about the role’s access patterns to determine whether you ought to delete it.
From the role detail page, navigate to the Access Advisor tab and investigate the list of accessed services and verify what the role was used for.
In the Access Advisor tab you can investigate the list of accessed services and verify what the role was used for.
This can also be done via the CLI:
The question often remains is this information enough to make important decisions on? For example:
What’s missing in both the above questions is context. Context of the role and if it is linked to anything. The problem with context is that it is often difficult to get without years of experience or up-to-date CMDBs/ documentation.
Using Overmind does not require any of the above. In fact, it was built to be used with no prior context. You can simply search for what you want, in this case ‘iam-role’. Overmind will do the work finding them even across multiple regions and accounts.
From here we can quickly distinguish any unused roles or policies because they won’t be linked to any other resources.
For example an unused role will look like this.
Whereas one that is currently in use will have links to other resources and look like this.
In Overmind you can expand out and discover what other resources it is linked to or being used by. Providing us with the context we were missing before.
From here we’ll be able to understand what this application is and the resources it needs to work out. Answering the question of what the impact would be if we were to remove these roles or policies. Now we have the missing context we can go ahead and proceed confidently knowing that our changes won’t have any unintended impact.
What if before making a application change Overmind could work out the blast radius and inform you on the impact? Or after a unsuccessful change you could go back and see a snapshot of what your application looked like before? Across all your AWS resources.
That’s what we are building and we would love you to join us on this journey. Get started today for free by signing up and creating an account here.