Understanding Context

It's essential to understand the context behind the findings that the report generates. Understanding the context behind the findings aids the assessor in triaging the results accurately.

This report generates findings on Policies that do not leverage resource constraints and identifies some attributes to help prioritize which ones to address - such as Privilege Escalation, Resource Exposure, and Data Exfiltration. These results help you to identify your IAM threat landscape and reduce blast radius. In the event of credential compromise, you can prevent an attacker from exploiting the risks mentioned above, in addition to preventing mass deletion, destruction, or modification of existing infrastructure.

However, this tool does not attempt to understand the context behind everything in your AWS account. It's possible to understand the context behind some of these things programmatically - whether the policy is applied to an instance profile, whether the policy is attached, whether inline IAM policies are in use, and whether or not AWS Managed Policies are in use. Only you know the context behind the design of your AWS infrastructure and the IAM strategy.

For example, an AWS Lambda policy used as a simple service checking the configuration of AWS infrastructure might be a good use case for resource constraints. Conversely, perhaps you applied the AdministratorAccess AWS-managed policy to an Instance Profile so that an EC2 instance can run Terraform to provision AWS resources via Infrastructure as Code. In the second example, the role is extremely permissive by design - and a tool can't automatically understand that context.

As such, the tool aims to:

  • Map out your risk landscape of IAM identity-based policies, enumerating the potential risks for a full IAM threat model
  • Identify where you can reduce the blast radius in the case of credentials compromise
  • Help you prioritize which ones to remediate
  • Provide a straightforward workflow to remediate
  • Provide a sufficient exclusions mechanism to programmatically define where deviations from resource constraints are by design

Assessment Recap

To recap: you've followed these steps to generate this report:

  • Downloaded the Account Authorization details JSON file
    • cloudsplaining download --profile default --output default-account-details.json
  • Generated your custom exclusions file
    • cloudsplaining create-exclusions-file --output-file exclusions.yml
  • Generated the report
    • cloudsplaining scan --input default-account-details.json --exclusions-file exclusions.yml
    • This generates three files: (1) The single-file HTML report, (2) The triage CSV worksheet, and (3) The raw JSON data file
Triaging workflow

An assessor can follow this general workflow:

  • Open a ticket in your organization's project management tool of choice (for example, JIRA or Salesforce) in the AWS account owner's project
  • Attach the HTML report, JSON Data file, and CSV worksheet
  • Ask the service/account owner team to fill out the Triage worksheet

When you ask the service/account owner team to fill out the Triage CSV worksheet, you can use some text like the following:

As part of our security assessment, our team ran Cloudsplaining on your AWS account. Cloudsplaining maps out the IAM risk landscape in a report, identifies where resource ARN constraints are not in use, and identifies other risks in IAM policies like Privilege Escalation, Data Exfiltration, and Resource Exposure/Permissions management. Remediating these issues, where applicable, will help to limit the blast radius in the case of compromised AWS credentials. We request that you review the HTML report and fill out the "Justification" field in the Triage worksheet. Based on the corresponding details in the HTML report, provide either (1) A justification on why the result is a False Positive, or (2) Identify that it is a legitimate finding.

Triaging considerations

When triaging your results, consider some of the factors listed below as you identify False Positives vs. legitimate findings. There are some scenarios where "Resource": "*" access is by design and is therefore a false positive. This section covers some of the common scenarios.

Infrastructure Creation roles:

IAM roles that create infrastructure via Infrastructure as Code Technologies (for example, Terraform or CloudFormation) require high permission levels to provision AWS infrastructure. These will usually be false positives. When you see these instances, make sure that these roles are adequately protected. For instance, make sure that roles within the AWS account are not able to assume this role or affect its configuration in any way. Additionally, consider restricting the trust policy so that a set of explicitly stated IAM principals are the only ones who can assume that role. Take special care to audit instances of sts:AssumeRole within this AWS account.

System roles vs. User Roles: System roles - IAM Roles applied to compute services, such as EC2 Instance Profiles, ECS Task Execution roles, or Lambda Task Execution roles - should almost always leverage resource ARN constraints for actions that perform "Write" actions. Exceptions to this could include Infrastructure provisioning or other edge cases.

Conversely, user roles will almost always be used against * resources for the sake of convenience, innovation, and avoiding overly restrictive limitations. In the user role scenario, consider:

  • Design context: is it appropriate? (For instance, maybe all your user roles don't need iam:*)
  • Environment: If this is a Dev environment, frequently-used user roles probably allow more permissions for innovation purposes. However, in later environments - especially production - commonly used user roles should be read-only - or the more permissive ones should be for break-glass scenarios only.
  • Regardless of the context: there should always be security guardrails in place, like Service Control Policies through AWS Organizations or IAM Permissions Boundaries to prevent against egregious mistakes.

Organization-specific results

For example, perhaps you allow kms:Decrypt for * resources (by design) in your organization for one reason or another. Cloudsplaining flags this as a result. However, there are mitigating controls in place. Firstly, you leverage strict resource-based KMS key policies to lock down all KMS keys, explicitly stating individual IAM principals that are allowed to use them. Secondly, you provision all KMS keys with CloudFormation or Terraform, so you are confident that this pattern is consistent across all KMS keys in your AWS accounts. Therefore, kms:Decrypt to * resources is not a finding you are concerned about. In this case, you decide it is acceptable to exclude kms:Decrypt from your results.

Common False Positive Scenarios

Conditions Logic:

This tool does not evaluate IAM Conditions logic. If your policies use wildcard resources but restrict according to condition keys, then it's possible this is a false positive. However, you might want to double-check the accuracy of the conditions logic in those IAM policies. While IAM conditions can be extremely powerful, implementation is also prone to human error. We suggest leveraging Parliament by Duo Labs (courtesy of Scott Piper), to lint your policies for accuracy - especially when IAM conditions are in use.

logs:CreateLogGroup and logs:PutLogEvent:

Depending on how your organization approaches CloudWatch Logs Agent configuration, IAM, and CloudWatch Logs Group naming conventions, it is sometimes near-impossible to prevent cross-contamination of logs or Log Injection to the Log Streams from other instance IDs. Cross-Contamination of CloudWatch Logs is an issue of its own that is definitely beyond the scope of this document - but consider this as a potential limitation by AWS when trying to identify a remediation plan.

Building the Exclusions File

After you have identified the False Positives, add the False Positive criteria to your custom Cloudsplaining exclusions file. The False Positives generally fall into one of two categories:

  • False positives that will occur across all of your AWS accounts, due to your organization-wide implementation strategy
  • False positives specific to this AWS account

To make the exclusions file, create a YAML file that we will use to list out exclusions with the create-exclusions-file command.

cloudsplaining create-exclusions-file

This will generate a file titled exclusions.yml in your current directory.

The default exclusions file contains these contents:

# Policy names to exclude from evaluation
# Suggestion: Add policies here that are known to be overly permissive by design, after you run the initial report.
  - "AWSServiceRoleFor*"
  - "*ServiceRolePolicy"
  - "*ServiceLinkedRolePolicy"
  - "AdministratorAccess" # Otherwise, this will take a long time
  - "service-role*"
  - "aws-service-role*"
# Don't evaluate these roles, users, or groups as part of the evaluation
  - "service-role*"
  - "aws-service-role*"
  - ""
  - ""
# Read-only actions to include in the results, such as s3:GetObject
# By default, it includes Actions that could lead to Data Leaks
  - "s3:GetObject"
  - "ssm:GetParameter"
  - "ssm:GetParameters"
  - "ssm:GetParametersByPath"
  - "secretsmanager:GetSecretValue"
# Write actions to include from the results, such as kms:Decrypt
  - ""

Add whatever values you want to the above depending on your organization's context. * Under policies, list the path of policy names that you want to exclude. * If you want to exclude a role titled MyRole, list MyRole or MyR* in the roles list. * You can follow the same approach for users and groups list.

  • Now, run the scan to generate a new Cloudsplaining report that considers your exclusions criteria. This way, you are working with a report version that consists of True Positives only.
cloudsplaining scan --input default.json --exclusions-file exclusions.yml

You can now proceed to the Remediation stage.


Prioritizing Remediation

Depending on the existing workload of the engineering team addressing your concerns, the team might ask to address high priority items first rather than addressing all items, especially if the report is quite large. In this scenario, consider instructing the team to address High Priority Risks and the usage of AWS-Managed Policies first.

High priority risks:

These include Privilege Escalation, Data Exfiltration, and Potential Resource Exposure/Permissions management. This report highlights each finding that has these high priority risks.

Moving from AWS Managed Policies over to custom policies:

AWS managed policies always include access to * resources because AWS provides these same policies universally to all customer accounts. If this report flags any AWS-managed policies, it means that the account/service owner team will not only have to implement resource constraints - they will have to create a custom IAM policy to do so. To limit this work, it is best to migrate away from the root cause of the problem - using AWS managed policies.

You can then queue the work for remediating the other Customer-managed policies that do not have the High-Priority Risks attributes. Implementing resource ARN constraints for True Positives is still important, since overly permissive "Write" actions can cause modification or deletion of AWS resources by a bad actor with compromised credentials, resulting in downtime.

Remediating the Findings

We suggest two options for remediating each finding:

  • Leveraging Policy Sentry, courtesy of Kinnaird McQuade, which generates policies with resource ARN constraints at user-specified access levels automagically.
  • Manually rewriting the policies

Leveraging Policy Sentry

For guidance on how to use Policy Sentry, please see the documentation here. This is highly suggested - within 10 minutes of learning the tool, creating a secure IAM policy becomes a matter of:

  • Generating the YAML template with policy_sentry create-template --output-file crud.yml --template-type crud
  • Literally copying/pasting resource ARNs into the template
  • Running policy_sentry write-policy --input-file crud.yml

Manually rewriting the IAM Policies

For guidance on how to write secure IAM Policies by hand, see the tutorial here. Just be aware - you'll spend a lot of time looking at the AWS Documentation on IAM Actions, Resources, and Condition Keys, which can become quite tedious and time-consuming.


Validating remediated policies

After you've rewritten your IAM policy, we suggest two options for validating that it will pass Cloudsplaining and alleviate any remaining concerns:

  • Run Cloudsplaining's scan-policy-file command, which scans a single JSON policy file instead of the entire AWS Account's Authorization details.
  • Leveraging Parliament by Duo-Labs, courtesy of Scott Piper
Using Cloudsplaining to Validate your Remediated Policies

You can validate that your remediated policy passes Cloudsplaining by running the following command:

cloudsplaining scan-policy-file --input policy.json --exclusions-file exclusions.yml

When there are no more results, it passes!

Using Parliament to Lint your Policies

parliament is an AWS IAM linting library. It reviews policies looking for problems such as:

  • malformed JSON
  • missing required elements
  • incorrect service prefix and action names
  • incorrect resources or conditions for the actions provided
  • type mismatches
  • bad policy patterns

This library duplicates (and adds to!) much of the functionality in the web console page when reviewing IAM policies in the browser.

You can use Parliament to scan your IAM policy with the following command:

parliament --file policy.json




The impact the risk would have on an organization if such a vulnerability were successfully exploited is rated according to criteria listed below. Note that these ratings are based on NIST 800-30 impact definitions.

  • Critical: The issue causes multiple severe or catastrophic effects on operations, assets or other organizations.
  • High: Causes produces severe degradation in mission capability to the point that the organization is not able to perform primary functions or results in damage to organizational assets.
  • Medium: Trigger degradation in mission capability to an extent the application is able to perform its primary functions, but their effectiveness is reduced and there may be damage to the organization's assets.
  • Low: Results in limited degradation in mission capability; the organization is able to perform its primary functions, but their effectiveness is noticeably reduced and may result in minor damage to the organization's assets.
Privilege Escalation

These policies allow a combination of IAM actions that allow a principal with these permissions to escalate their privileges - for example, by creating an access key for another IAM user, or modifying their own permissions. This research was pioneered by Spencer Gietzen at Rhino Security Labs. Remediation Guidance can be found here.

Resource Exposure

Resource Exposure actions allow modification of Permissions to resource-based policies or otherwise can expose AWS resources to the public via similar actions that can lead to resource exposure - for example, the ability to modify AWS Resource Access Manager.

Infrastructure Modification

Infrastructure Modification describes IAM actions with "modify" capabilities, and can therefore lead to Resource Hijacking, unauthorized creation of Infrastructure, Backdoor creation, and/or modification of existing resources which can result in downtime.

Data Exfiltration

Policies with Data leak potential allow certain read-only IAM actions without resource constraints, such as s3:GetObject, ssm:GetParameter*, or secretsmanager:GetSecretValue. Unrestricted s3:GetObject permissions has a long history of customer data leaks. ssm:GetParameter* and secretsmanager:GetSecretValue are both used to access secrets. rds:CopyDBSnapshot and rds:CreateDBSnapshot can be used to exfiltrate RDS database contents.

Roles Assumable by Compute Services

IAM Roles can be assumed by AWS Compute Services (such as EC2, ECS, EKS, or Lambda) can present greater risk than user-defined roles, especially if the AWS Compute service is on an instance that is directly or indirectly exposed to the internet. Flagging these roles is particularly useful to penetration testers (or attackers) under certain scenarios. For example, if an attacker obtains privileges to execute ssm:SendCommand and there are privileged EC2 instances with the SSM agent installed, they can effectively have the privileges of those EC2 instances. Remote Code Execution via AWS Systems Manager Agent was already a known escalation/exploitation path, but Cloudsplaining can make the process of identifying theses cases easier.

Trust Policy

A JSON policy document in which you define the principals that you trust to assume the role. A role trust policy is a required resource-based policy that is attached to a role in IAM. The principals that you can specify in the trust policy include users, roles, accounts, and services.

This definition was taken from the AWS Documentation here.


An entity in AWS that can perform actions and access resources. A principal can be an AWS account root user, an IAM user, or a role.


An IAM identity that you can create in your account that has specific permissions. An IAM role has some similarities to an IAM user. Roles and users are both AWS identities with permissions policies that determine what the identity can and cannot do in AWS. However, instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it. Also, a role does not have standard long-term credentials such as a password or access keys associated with it. Instead, when you assume a role, it provides you with temporary security credentials for your role session.

We are particularly interested in roles used for compute services - i.e., Compute Service Roles.

This definition was taken from the AWS Documentation here.

Managed Policy

There are two types of Managed Policies: AWS-managed policies and Customer-managed policies. They are described below.

Criteria for selecting Managed Policies versus Inline policies can be found in the AWS documentation here.

Customer-managed policy

AWS documentation on Customer-managed policies can be found here.

The following diagram illustrates customer managed policies. Each policy is an entity in IAM with its own Amazon Resource Name (ARN) that includes the policy name. Notice that the same policy can be attached to multiple principal entities—for example, the same DynamoDB-books-app policy is attached to two different IAM roles.

Customer-managed policy diagram

AWS-managed policy

An AWS managed policy is a standalone policy that is created and administered by AWS. Standalone policy means that the policy has its own Amazon Resource Name (ARN) that includes the policy name. For example, arn:aws:iam::aws:policy/IAMReadOnlyAccess is an AWS managed policy.

AWS documentation on AWS-managed policies can be found here.

The following diagram (taken from the AWS documentation) illustrates AWS managed policies. The diagram shows three AWS managed policies: AdministratorAccess, PowerUserAccess, and AWSCloudTrailReadOnlyAccess. Notice that a single AWS managed policy can be attached to principal entities in different AWS accounts, and to different principal entities in a single AWS account.

AWS-managed policy diagram

Inline Policy

An inline policy is a policy that's embedded in an IAM identity (a user, group, or role). That is, the policy is an inherent part of the identity. You can create a policy and embed it in a identity, either when you create the identity or later.

AWS documentation on inline policies can be found here.

The following diagram illustrates inline policies. Each policy is an inherent part of the user, group, or role. Notice that two roles include the same policy (the DynamoDB-books-app policy), but they are not sharing a single policy; each role has its own copy of the policy.

Inline policy diagram

Inline policies are useful if you want to maintain a strict one-to-one relationship between a policy and the identity that it's applied to. For example, you want to be sure that the permissions in a policy are not inadvertently assigned to an identity other than the one they're intended for. When you use an inline policy, the permissions in the policy cannot be inadvertently attached to the wrong identity. In addition, when you use the AWS Management Console to delete that identity, the policies embedded in the identity are deleted as well. That's because they are part of the principal entity.

Exclusions configuration

The Cloudsplaining exclusions configuration is shown below. You can leverage this to ensure reusability, for next time you run the scan.