Custom Security Checks for AWS Cloud Control Provider with Checkov

5 minute read
, , , ,

Checkov is an open-source static code analysis tool designed to scan Infrastructure as Code (IaC) for security and compliance issues. It supports multiple frameworks including Terraform, CloudFormation, Kubernetes, and more. The tool helps identify misconfigurations, security risks, and compliance violations before they make it to production.

The AWS Cloud Control (AWSCC) provider for Terraform is relatively new and lacks the extensive ecosystem support that the traditional AWS provider enjoys. This includes security scanning tools like Checkov, which currently doesn’t have built-in support for AWSCC resources. This becomes particularly important as organizations started adopting the AWSCC provider for its coverage of AWS services.

My Journey with Checkov

I have worked with checkov policies as an easy alternative to anything out there from a infrastructure policy engine standpoint. The ease of use with a binary enforcing some of the checks against your infrastructure configuration was an easy win at the earlier stages. I personally do feel that it has become noisy in comparison to other alternatives as the severity categorization is under a license.

Baseline policies and examples

Seeing the gap in policy coverage for AWSCC resources, I decided to create custom Checkov policies to address this. Since Checkov uses Python and I was comfortable with it, I started porting over existing AWS provider checks. The challenges:

  • The PRs haven’t moved much from the time I have opened it and I have been updating it with the main branch updates
  • There isn’t an exact correlation or map between AWS and AWSCC resources by which you can translate that over

Despite these challenges, I was able to develop a set of baseline security checks for the AWSCC provider that can be integrated with Checkov. I am not going to go into the details of how a checkov policy is structured. Here’s a simple example of a custom check ( probably the first one I wrote ) that ensures no hardcoded AWS credentials in the provider configuration:

 1from checkov.terraform.checks.provider.base_check import BaseProviderCheck
 2from checkov.common.models.enums import CheckCategories, CheckResult
 3
 4class AWSCCCredentials(BaseProviderCheck):
 5    def __init__(self) -> None:
 6        name = "Ensure no hard coded AWS access key and secret key exists in provider"
 7        id = "CKV_AWS_41"
 8        supported_provider = ["awscc"]
 9        categories = [CheckCategories.SECRETS]
10        super().__init__(name=name, id=id, categories=categories, supported_provider=supported_provider)
11
12    def scan_provider_conf(self, conf: Dict[str, List[Any]]) -> CheckResult:
13        result = CheckResult.PASSED
14        if self.secret_found(conf, "access_key", access_key_pattern):
15            result = CheckResult.FAILED
16        if self.secret_found(conf, "secret_key", secret_key_pattern):
17            result = CheckResult.FAILED
18        return result

The check will fail if it finds either an access key or a secret key in the provider configuration. This helps prevent accidental credential exposure in version control systems.

Scaling with GenAI

After the first few iterations of policies, it was evident that I could use a GenAI coding agent to complete the 100 odd policies I was planning to tackle here. The approach was this :

  • Ask Amazon Q developer to identify security hub controls for a service or AWS checkov check and write a policy/check for AWSCC.
  • Ask Amazon Q developer to add a passing and failing example for the check you just wrote in the new test framework checkov uses. I had some baseline examples I created for the PRs as something which could be used to create the newer ones with.
  • Validate the passing and failing checks are accurate using terraform validate
  • Add a GitHub action workflow which would validate the expected pass/fail checks against the actual ones to keep the iterative process honest.

For example, when creating the EKSPublicAccess check, I prompted Amazon Q with “Write a Checkov policy for AWSCC EKS clusters that ensures public endpoint access is disabled” and it generated both the policy and test examples that I could quickly validate and integrate.

The result is what you see in the repository here.

Contributing back to checkov

I’ve submitted pull requests to the Checkov repository to integrate these checks:

  • PR #6647
  • PR #7043. This is a subset of my initial list of checks after I moved them over as custom checks.

Features

The repository includes a comprehensive set of security checks for AWSCC provider resources, with several key features:

  • Extensive Coverage: Over 140 different security checks covering various AWS services and security best practices
  • Working Examples: Each check includes corresponding Terraform examples that demonstrate both compliant and non-compliant configurations
  • Policy Validation: All examples are run against the policies to ensure they correctly identify security issues
  • Action Results Summary: The GitHub Action workflow provides a summary of results, making it easy to identify if any checks are not operating correctly
  • Easy Integration: Simple to integrate with existing CI/CD pipelines

The examples directory contains Terraform files that correspond to each check, allowing you to test and verify the behavior of the checks against real configurations. When the GitHub Action runs, it produces a summary that shows which checks passed and failed, providing a quick way to validate that all checks are functioning as expected.

What’s Next?

The goal is to continue expanding the coverage of security checks for AWSCC provider resources, focusing on any new controls get listed.

Integrating with GitHub Actions

You can easily integrate these custom checks into your CI/CD pipeline using GitHub Actions. Here’s how to set it up:

 1- name: Run Checkov
 2  id: checkov
 3  uses: bridgecrewio/checkov-action@v12
 4  with:
 5    directory: .
 6    framework: terraform
 7    soft_fail: true
 8    output_format: cli,sarif
 9    output_file_path: console,results.sarif
10    external_checks_repos: https://github.com/quixoticmonk/checkov-awscc-custom-checks.git?ref=checks

Do note the checks branch reference as external_checks_repo gets cloned and I found an initial run started failing on my own examples list. This configuration will run Checkov against your Terraform files, including the custom AWSCC checks from the external repository. The results will be displayed in the console and also saved as a SARIF file for further analysis or integration with other tools.

Conclusion

As AWS Cloud Control adoption grows, having robust security checks becomes increasingly important. These custom Checkov policies help bridge the gap between the traditional AWS provider and AWSCC, ensuring consistent security practices across your infrastructure. I encourage you to try these checks in your environment and contribute additional policies to expand coverage further.