How to monitor IAM Roles activities?

Oftentimes as part of delivering a service, a vendor will request a role for cross-account access, in order to aggregate data or perform some actions in the customer’s account. However, beyond modifying an IAM policy to restrict access, customers don’t think much about auditing the use of these roles once live.

In this post in our series on querying CloudTrail with Athena, we take a look at how you can keep tabs on access patterns on assumed roles.

Why does utilization of IAM Roles matter?

While a particular IAM privilege or role may seem innocuous by name (see ReadOnlyAccess), there could be reasons for concern in the nature, pattern or frequency of access to the customer account.

Security concerns

You may utilize a third-party SaaS solution that requires access to your AWS environment. However, if this role permits it, the provider may attempt to inspect or modify other resources in your environment.

For example, you may expect a vendor to inspect your EC2 instances with DescribeInstances, but you may not expect them to generate an IAM Credential Report (iam:Generate* is enabled on the AWS ReadOnlyAccess policy).

Availability concerns

We have heard plenty of stories from customers having reached service limits and being denied service in the AWS Console because a third-party role is busy aggregating data on a very high frequency.

Cost concerns

Queries on some services have a direct impact on cost. The two common sources of sudden spikes in cost when used carelessly are queries to CloudWatch and Cost Explorer

To manage the risk of third party vendor access to your cloud, you must keep an eye on their usage for security, availability, and cost reasons.

So what can I do to monitor IAM roles?

The good news is that you can use Athena with your CloudTrail Events to audit your IAM roles activities. With that, you will be able to retrieve all the answers to the concerns.

Say you want to audit GorillaStack’s role for cross-account access:

For a given role, let me see all API calls

-- remember, you can add account, region and day filters
SELECT eventname, eventsource, eventtime, requestid, eventid, recipientaccountid, requestparameters
FROM cloudtrail_logs
WHERE year = '<year>'
        AND month = '<month>'
        AND useridentity.arn = '<insert your role here>';

Show me all identities attempting a particular API call

SELECT useridentity, eventtime, requestid, eventid, recipientaccountid, requestparameters
FROM cloudtrail_logs
WHERE year = '<year>'
        AND month = '<month>'
        AND eventname = '<eventname (e.g. CreateUser)';

Show me who is performing all the AssumeRole requests

WITH dataset as (SELECT
    useridentity.arn as userArn,
    json_extract(requestparameters, '$.roleArn') AS roleArn
  FROM cloudtrail_logs
  WHERE year = '<year>'
    AND month = '<month>'
    AND eventname = 'AssumeRole'
)
SELECT roleArn, userArn, count(userArn) as count
FROM dataset
GROUP BY roleArn, userArn
ORDER BY count desc;

Note, this will show you all AssumeRole requests, not just those performed by third parties. It should be easy enough to add to the query to filter our unwanted events.

Closing thoughts on securing third party vendor access of your cloud environment

Gone were the days of looking back through CloudTrail retrospectively, to catch mistakes or threats that occurred days, months, years in the past.

Take a proactive approach to catch these potential threats in real time before they become security incidents. Learn how you can manage them from Slack, Jira, ServiceNow or a lambda function with GorillaStack Real Time Events.

Reach out to us on our public Slack channel to let us know what you think.