IAM roles
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.
Working with IAM roles
Auditing roles
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.
In AWS
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:
- Can I remove this IAM role that has not been used in 89 days? What happens if it is part of a service that is used every 120 days?
- How can I be sure that I can I remove a role that has no activity?
- I know the role was used, but which AWS resource used it? A lambda function? An EKS pod?
Context is key.. but often missing
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.
A solution with Overmind
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.
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.
We aren’t stopping here..
With Overmind's risks you can surface incident-causing config changes as part of your pull request. When a pull request is opened and a Terraform plan is executed you can calculate the potential impact (or blast radius) of your change. By parsing the Terraform plan output and then using only read-only AWS credentials it can map out your infrastructure. It queries AWS directly and discovers relationships automatically, working out what the actual impact of your change is. Even for things not managed under Terraform.
From this you are then able to check the affected items to see if there is anything unexpected. If you notice that the change might affect more than you thought, you can modify either your code, or the way you plan to roll out and monitor the change to account for it. You can then share this change or graph with your team or the change advisory board.
From the blast radius it also provides a list of human readable risks that can be reviewed prior to running Terraform apply. These risks can either be commented back as part of your CI / CD pipeline or viewed in the app. Using our Github action you can combine this as part of your workflow. The action will comment back on the pull request telling you the blast radius (everything that might be affected by the given change).
Inside the app you can see the full blast radius in a interactive graph along with any metadata Overmind was able to get from AWS. When you're ready to start the change, Overmind will take a snapshot before and after to validate that the change went through as intended.
Don’t just take our word for it…
We want to make it as easy as possible to get started, because of this we have created an example repository. It shows how to run terraform on GitHub Actions and automatically submit each PR's changes to Overmind and report back the blast radius as a comment on the PR. This way you can get started easily with either your personal or org AWS account.
- Check out the example Terraform example repo here.
- Get started with Overmind for free here.
- Or join our Discord to take part in the next wave of Devops tools.
.gif)
