This post was co-written by Kinnaird McQuade and Barak Schoster.
AWS IAM allows developers to control access to AWS service APIs and specific resources according to the principle of least privilege. However, writing security-conscious IAM policies by hand can be prone to human error and introduce security risks by allowing users or machine roles excessive privileges. Overly permissive identity-based policies could allow unintentional capabilities such as privilege escalation, exposure of resources, data exfiltration, credentials exposure, or infrastructure modification. By minimizing the number of roles with excessive permissions, you can limit the blast radius in the case of compromised credentials.
IAM policy security scanning tooling has improved significantly in recent years, largely focused on securing policies that are already deployed in AWS accounts or scanning JSON files containing the policies. IAM policies are also often written earlier in the development lifecycle as infrastructure as code (IaC).
But what if you could assess IAM policies in all of the stages of the development lifecycle?
Identifying security issues the moment a developer writes an insecure policy in their IDE or when a policy is introduced to a codebase in the CI/CD pipeline can prevent security risks from being introduced to the environment in the first place. Supporting multiple infrastructure as code (IaC) technologies such as Terraform, CloudFormation, and the Serverless Framework can help identify these security issues in whatever technology a developer uses.
I worked together with Kinnaird McQuade, the creator of Cloudsplaining, to help developers identify IAM policies security issues right in their integrated development environment (IDE) or continuous integration (CI) pipelines, shifting the policy inspection process left. By combining the powers of Cloudsplaining and Checkov, our goal was to help organizations assess IAM policies in both build-time and runtime.
In this post, we’ll introduce the two tools, show how to start using them, and share their experience developing the integration and open-sourcing it as a set of brand-new Checkov policies.
Intro to Cloudsplaining
Kinnaird is also the author of Policy Sentry, an AWS IAM least privilege policy generator tool that enables users to write secure IAM policies easily by specifying resource addresses and access levels in simple YAML templates. He found that once IaC developers or AWS administrators gain familiarity with Policy Sentry (which is quite easy to use), adoption starts very quickly.
However, if you’ve already been using AWS, there is probably a large backlog of overly permissive IAM policies that could use a security uplift. That was often the first question people would ask after learning about Policy Sentry: “What should I do about the IAM Policies that I’ve already written?”
That’s where Cloudsplaining comes in—helping to programmatically identify existing policies that can be fixed.
Cloudsplaining identifies least privilege violations in AWS IAM policies and generates an HTML report. It can scan all the policies in an AWS account, or it can scan a single policy file.
Cloudsplaining also identifies IAM actions that do not leverage resource constraints and thus can present certain risks to the AWS account in question without restriction. These risks include:
- Privilege Escalation: The ability to modify users, roles, policies, or paths to expand one’s own permissions
- Resource Exposure: The ability to modify resource-based policies
- Data Exfiltration: The ability to exfiltrate S3 objects, SSM parameters, or secrets
- Credentials Exposure: The ability to make API calls that return credentials in the API response
- Infrastructure Modification: The ability to modify AWS infrastructure, which can lead to resource hijacking, unauthorized creation of infrastructure, backdoor creation, or destruction of resources that could result in downtime
How to use Cloudsplaining
Cloudsplaining can be installed as a PyPi package by running:
pip3 install --user cloudsplaining
After setting up AWS credentials, run the following command:
cloudsplaining scan --exclusions-file exclusions.yml --input-file examples/files/example.json --output examples/files/
It will create an HTML report like this:
The report can be reviewed by security practitioners and developers to determine what IAM risks in a given running AWS environment should be prioritized and mitigated by the business context (Should X have access to Y? What would be the risk if so?).
Intro to Checkov
Checkov is a static analysis tool for IaC. It enables authoring policy-as-code in Python on top of Terraform, CloudFormation, Serverless framework, and others to ensure that DevOps and security best practices are in place before deploying resources to production. You can use Checkov through the VS Code extension, a pre-commit hook, or embed it into your CI/CD pipelines just like unit and integration tests, to catch bad configurations early in the development lifecycle.
How to use Checkov
Checkov, like Cloudsplaining, can be installed as a PyPi package by running:
pip3 install --user checkov
And we can scan a directory with IaC manifests using the following command:
checkov -d .
The output is a list of policy violations by resource. This enables analysis of those manifests early on the development lifecycle.
Integrating Checkov and Cloudsplaining
Cloudsplaining analyzes every IAM policy for possible over-privileged permissions and suggests guidance on minimizing the attack surface for those policies.
When writing Checkov policies for AWS IAM, we realized that some non-trivial analysis was required to provide context around findings. For example, answering “If I grant the following access to a user, what bad things can happen?” Luckily, Cloudsplaining already offered this capability. After some conversation on the Cloud Security Forum, they thought there was a great opportunity to combine the power of the two projects.
Analyzing IAM policies in code
By incorporating Cloudspaining’s IAM analysis into Checkov policies, Checkov users can identify IAM issues in IaC early in the development lifecycle.
The integration between Checkov and Cloudsplaining resulted in five new policies available from Checkov v1.0.844:
- CKV_AWS_107: Ensure IAM policies do not allow credentials exposure
- CKV_AWS_108: Ensure IAM policies do not allow data exfiltration
- CKV_AWS_109: Ensure IAM policies do not allow permissions management/resource exposure without constraints
- CKV_AWS_110: Ensure IAM policies do not allow privilege escalation
- CKV_AWS_111: Ensure IAM policies do not allow write-access without constraints
Let’s take the same IAM policy in Terraform, CloudFormation, and Serverless and see the results from the Cloudsplaining and Checkov policies:
After storing those files in a local directory, we can start scanning them using the command:
checkov -d .
Which provides the following results showing what IAM policies should be fixed in the IaC:
Running Cloudsplaining and Checkov in a real-life environment
Embedding IAM best practices guardrails earlier in the development lifecycle allows engineers to get fast feedback on code they’re working on when they’re working on it. That not only saves time spent context-switching but also enables more independence while creating resources in the cloud.
That having been said, a production environment has a lot of moving parts, and a complete IAM assessment can only truly be achieved by scanning the runtime AWS account. For that reason, we recommend using the Cloudsplaining policies for both build-time with Checkov and in runtime for real-time analysis and notifications.
Why take an open-source approach?
The open-source approach allows multiple organizations and individual contributors to collaborate on projects. Anyone can add new features, add an issue, resolve one, create a copy of the project for their use, get alerted when changes happen, quickly bring these changes into their code, and collaborate with the community when possible.
When creating a policy-as-code project like Checkov, we benefit from the wisdom of the crowd. Having developers share best practices accelerates the ability to cover more use cases in the cloud and IaC space. Cloudsplaining has a great way to analyze AWS IAM best practices. The combination of the two open-source projects enables taking those best practices and turning them into CI/CD pipeline policies for the community to learn from and adopt.
If you would like to join any of the open-source projects, take a look at the contribution guidelines of Cloudsplaining and Checkov.
