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:
To recap: you've followed these steps to generate this report:
cloudsplaining download --profile default --output default-account-details.json
cloudsplaining create-exclusions-file --output-file exclusions.yml
cloudsplaining scan --input default-account-details.json --exclusions-file exclusions.yml
An assessor can follow this general workflow:
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.
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:
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,
* resources is not a finding you are concerned about. In this case, you decide it is acceptable to exclude
kms:Decrypt from your results.
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.
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.
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:
To make the exclusions file, create a YAML file that we will use to list out exclusions with the
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. policies: - "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 roles: - "service-role*" - "aws-service-role*" users: - "" groups: - "" # Read-only actions to include in the results, such as s3:GetObject # By default, it includes Actions that could lead to Data Leaks include-actions: - "s3:GetObject" - "ssm:GetParameter" - "ssm:GetParameters" - "ssm:GetParametersByPath" - "secretsmanager:GetSecretValue" # Write actions to include from the results, such as kms:Decrypt exclude-actions: - ""
Add whatever values you want to the above depending on your organization's context.
policies, list the path of policy names that you want to exclude.
* If you want to exclude a role titled
MyR* in the
* You can follow the same approach for
cloudsplaining scan --input default.json --exclusions-file exclusions.yml
You can now proceed to the Remediation stage.
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.
We suggest two options for remediating each finding:
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:
policy_sentry create-template --output-file crud.yml --template-type crud
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.
After you've rewritten your IAM policy, we suggest two options for validating that it will pass Cloudsplaining and alleviate any remaining concerns:
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!
parliament is an AWS IAM linting library. It reviews policies looking for problems such as:
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.
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 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 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.
Policies with Data leak potential allow certain read-only IAM actions without resource constraints, such as
s3:GetObject permissions has a long history of customer data leaks.
secretsmanager:GetSecretValue are both used to access secrets.
rds:CreateDBSnapshot can be used to exfiltrate RDS database contents.
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.
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.
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.
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.
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.
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 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.
The Cloudsplaining exclusions configuration is shown below. You can leverage this to ensure reusability, for next time you run the scan.