Sensitive IAM Actions

There exists no definitive list of Sensitive IAM Actions that can lead to credential or data access, privilege escalation, or making resources public. Several tools have tried to take an opinion on this issue, but there is no centralized list of these sensitive IAM Actions that tools and IAM policy writers can reference.

This project is a list of IAM Actions that fall into one of four risk categories:

  • Credential Exposure
  • Data Access
  • Privilege Escalation
  • Resource Exposure

The addition of an action to these lists can be subjective. Is a pull request in a CodeCommit repo sensitive? What about the comments in an AWS Support case? It depends on what the person puts in. Others can be more obvious, like the list of users in a Cognito user pool, data in a DynamoDB table, or access to the data in an ElasticSearch cluster.

Using the Repo

You can pull any of the files from Github directly into your automations. Each set of parsed into these files:

  • A list of actions annotated with SAR information in JSON and YAML.
  • JSON Policy documents you can attach to your users and roles to Deny actions in specific risk categories.

Customizing the Policies

To process the policy and switch to an Allow:

curl -s \
	| jq '.Statement[0].Effect="Allow"'

To process the policy and switch to NotResource, thereby allowing these actions for specific resources:

curl -s \
	| jq '. | del(.Statement[0].Resource) | . + {NotResource: ["MyBucket", "MyOtherDDBTable"]}'

Note: you must still have an identity or resource based policy to allow the actions. This use of NotResource will just exclude those resources from being denied.

To remove an action or service from the list:

curl -s \
	| jq '. | del(.Statement[0].Action[] | select (.|startswith("workmail")))'


Adding a new sensitive action is as simple as updating the actions.yaml file with the new sensitive action. A GitHub action will run to update the annotated files and the JSON policies.

Future Work

While the data access actions are generally comprehensive, they may not work for all use cases. A FinOps user might not need to run cloudtrail:LookupEvents or lambda:GetFunction and access source code. A security auditor or incident response person would need those permissions. Breaking down the data access into sub-categories like source code, possible PII, etc., may need to be considered.

Prior Art

Several experts in the cloud security community have built tooling to wrangle the complexity of AWS IAM and to parse AWS’s Service Authorization Reference. This repo is based on the work from:

Blog Posts & Articles