cloudtracker v2.1.5 releases: find over-privileged IAM users and roles

cloudtracker

CloudTracker reviews CloudTrail logs to identify the API calls made by an actor and compares this with the IAM privileges that the actor has been granted to identify privileges that can be removed.

CloudTracker uses AWS CloudTrail logs and IAM policy information for an account. CloudTrail records the API calls made in an account but does have limitations. The most significant is data level actions are not recorded in CloudTrail, such as S3 object access. CloudTrail can be configured to log some of these data level activities, but there are still some AWS API calls that are never recorded in CloudTrail; therefore, CloudTracker can’t determine if a user with these privileges is over-privileged.

Instead of using CloudTrail logs, an alternative solution would have used AWS’s Access Advisor service, but that has a number of limitations that caused us to focus on CloudTrail logs instead. First, there are no API calls to collect information from Access Advisor. The only way of viewing Access Advisor information is through the web UI. Netflix uses Access Advisor via their Aardvark and RepoKid tools and works around this limitation by using PhantomJS to log in and scrape the data.

Another major limitation with Access Advisor is that you can’t trace individual users as they assume roles within an account or across accounts. Finally, the information available from the Access Advisor is not very granular. For example, Access Advisor cannot tell you how often a privilege was used, what resources were acted on, or the specific API call used. CloudTracker does not currently take resources into account either, but because its source of truth is CloudTrail logs, it can be modified in the future to display more detailed information and offer tighter privilege restriction advice based on resource attributes.

Changelog v2.1.5

• Uses github workflows to deploy new versions

Setup

Step 1: Setup CloudTracker

python3 -m venv ./venv && source venv/bin/activate
pip install cloudtracker

Note: To install with ElasticSearch support, see the ElasticSearch docs.

Step 2: Download your IAM data

Download a copy of the IAM data of an account using the AWS CLI:

mkdir -p account-data
aws iam get-account-authorization-details > account-data/demo_iam.json

Step 3: Configure CloudTracker

Create a config.yaml file with contents similar to:

athena:
  s3_bucket: my_log_bucket
  path: my_prefix
accounts:
  - name: demo
    id: 111111111111
    iam: account-data/demo_iam.json

This assumes your CloudTrail logs are at s3://my_log_bucket/my_prefix/AWSLogs/111111111111/CloudTrail/ Set my_prefix to ” if you have no prefix.

Step 4: Run CloudTracker

CloudTracker uses boto and assumes it has access to AWS credentials in environment variables, which can be done by using aws-vault.

You will need the privilege arn:aws:iam::aws:policy/AmazonAthenaFullAccess and also s3:GetObjectand s3:ListBucket for the S3 bucket containing the CloudTrail logs.

Once you’re running in an aws-vault environment (or otherwise have your environment variables setup for an AWS session), you can run:

cloudtracker --account demo --list users

This will perform all of the initial setups which takes about a minute. Subsequent calls will be faster.

Clean-up

CloudTracker does not currently clean up after itself, so query results are left behind in the default bucket aws-athena-query-results-ACCOUNT_ID-REGION.

If you wanted to get rid of all signs of CloudTracker, remove the query results from that bucket and in Athena run DROP DATABASE cloudtracker CASCADE

Use

Copyright 2018 Duo Security