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 a 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’s 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:

$ aws iam generate-service-last-accessed-details --arn arn:aws:iam::1234567:role/role-name
{
    "JobId": "10c3dc31-6ccc-69d2-1185-91e9ad363831"
}

$ aws iam get-service-last-accessed-details --job-id 10c3dc31-6ccc-69d2-1185-91e9ad363831
{
    "JobStatus": "COMPLETED",
    "JobType": "SERVICE_LEVEL",
    "JobCreationDate": "2023-04-25T12:28:18.712000+00:00",
    "ServicesLastAccessed": [
        {
            "ServiceName": "AWS Security Token Service",
            "LastAuthenticated": "2023-04-25T11:49:09+00:00",
            "ServiceNamespace": "sts",
            "LastAuthenticatedEntity": "arn:aws:iam::944651592624:role/aws-source-pod",
            "LastAuthenticatedRegion": "eu-west-2",
            "TotalAuthenticatedEntities": 1
        }
    ],
    "JobCompletionDate": "2023-04-25T12:28:20.485000+00:00",
    "IsTruncated": false
}

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 CMDB’s/ 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.
For example a 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 polices. 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..

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. Add your name to our waiting list to register your interest → https://overmind.tech