When building secure cloud infrastructure, our mantra at Bridgecrew is to use the least amount of code to describe the maximum set of configuration permutations. By design, Terraform enables that reusability and scalability through variables, templating, and a workflow that operationalizes modularity.
As you can see in the simplified Terraform development lifecycle below, each stage contains more context around what the end-state environment will look like:
- Writing code: Low context, default values can be evaluated
- Plan: Medium context, dynamic values from environment variables and CLI are resolved
- Apply: High context, the plan is resolved, and API interaction with production environment is performed
- Runtime: Very high context where the end state of the environment is being laid out as runtime configuration even if there is a drift from the Terraform state that is being created on the apply stage.
The Terraform plan stage often contains dynamic values that do not exist in plain Terraform code and thus provides a more complete representation of what configuration changes are going to be applied. Checkov now supports scanning Terraform plan output so that you can apply the same security and compliance policies to more context-rich code. 🎉
In addition to our recently announced support for full variable rendering and external module scanning, this functionality (available from Checkov version 1.0.649) enables teams to save countless code review hours spent manually authorizing configuration changes.
Scanning throughout the Terraform development pipeline
When running Checkov (or Bridgecrew CLI), we recommend scanning throughout the development lifecycle to get the most comprehensive coverage:
- Scan terraform with a pre-commit hook
- Add Checkov or Bridgecrew CLI to your build pipeline
- Apply code fixes via pull requests using Bridgecrew’s GitHub App
- Scan the Terraform plan output
- Continuously scan your runtime cloud environment using Bridgecrew
Keep in mind that Terraform plan output can contain sensitive environment variables, so it’s not recommended to keep secrets on uncontrolled endpoints.
To see Terraform plan scanning in action, go through the following steps with TerraGoat, our vulnerable-by-design Terraform project, or on a sample plan file from the Checkov unit test directory.
git clone https://github.com/bridgecrewio/terragoat.git cd terraform/aws terraform init terraform plan --out tfplan.binary terraform show -json tfplan.binary > tfplan.json checkov -f tfplan.json
Running Checkov against a Terraform plan file will return output such as:
In addition to Checkov and Bridgecrew CLI supporting Terraform plan scanning, Bridgecrew’s new native Terraform Cloud integration does as well. By leveraging HashiCorp’s policy-as-code engine, Sentinel, Bridgecrew adds hundreds of out-of-the-box policies to each Terraform workspace run, blocking
terraform apply changes if misconfigurations are identified.
Securing advanced applications built on top of complex infrastructure constructs requires tightened controls over creating and using those dynamic values. By automating variable management and relying on extracted modules to carry security into provisioned resources, DevOps teams can focus more on serving up-to-date infrastructure and less on gatekeeping coding standards.
Try it out for yourself, and let us know what you think in our #CodfiedSecurity Slack channel.