Pay for GorillaStack on the AWS SaaS Marketplace10 Oct 2019
Access More Useful Data With The New Lambda Payload Schema24 Oct 2019
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.
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
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.
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.