Finding and fixing Terraform misconfigurations in variables

It’s been almost a year since we launched our open-source infrastructure as code (IaC) scanner, Checkov, with basic Terraform scanning support. Since then, we’ve received dozens of contributions and feature requests to take it to the next level.

In addition to expanding its breadth of supported frameworks and policies, we’re also devoted to improving its depth. With our fantastic community’s help, we’re excited to announce support for one of our most frequently requested features—Terraform variable evaluation.

This release owes major kudos to Rob Eden, who put a lot of time and effort into implementing, testing, and documenting this update. Thanks, Rob!  💜

Checkov variable evaluation

Evaluate Terraform variables, locals, and .tfvars

When writing new Terraform templates for cloud resources that reference one other, you’re creating a graph of dependencies between blocks of Terraform variables, locals, data, resources, and output. When trying to spot a misconfiguration of a resource, it is important to traverse that graph to analyze each configuration value that is impacting the resource.

To demonstrate how variable evaluation with Checkov works, let’s run through the following example that contains a misconfigured CloudTrail bucket:

CloudTrail bucket

As you can see, the  acl parameter on the aws_s3_bucket.cloudtrail resource is referencing a Terraform variable defined in a separate block called var.acl. The parameter in the referenced block is set to “public-read-write“, which is a potential cloud security risk that exposes the AWS S3 bucket publicly for read and write access. This bucket is referenced by a CloudTrail resource which contains AWS API call auditing which introduces the risk of data tampering.

Another referenced parameter that leads to misconfiguration is enable_log_file_validation which is turned off and versioning_enabled which is not enabled. When enabled, both should help to keep a reliable data source of auditing logs.

Similarly, parameters can be defined in variable definition files (.tfvars) in the following format:

acl = "public-read-write"

Using .tfvars makes it easier to maintain and manage Terraform module configuration in centralized templates. Checkov can now render and evaluate those variables prior to the terraform plan stage by running checkov -d ${TERRAFORM_DIRECTORY} on folders containing both the Terraform code and the .tfvars file. With this update, Checkov can now show us the source of the misconfig in the .tfvars file or variable blocks. To be compliant with CIS best practices such as “Ensure CloudTrail log file validation is enabled” and “Ensure the S3 bucket CloudTrail logs to is not publicly accessible,” without breaking the dependencies, we’ll need to manually fix them at the source.

Variable misconfig fixes using Bridgecrew’s Resource Explorer

Bridgecrew’s cloud dependency graph takes dependency mapping of infrastructure as code to a whole new level by analyzing the best fix location on top of a specific violation.

In the example below, the S3 parameter ignore_public_acls is referencing a variable defined in another resource block, Variables.tf:

Variable misconfig fixes using Resource Explorer

Addressing the issue in the referring resource would fix the issue but it would also break our ability to maintain code in a configurable format using variables files. Instead, we want to implement it at the ideal fix location. To do that, Bridgecrew traverses the Terraform graph, analyzes where the fix should be applied, and provides the code change that can be implemented with a pull request.

Bridgecrew also maps out and exposes dependent resources, providing a contextual blast radius that might be impacted by the misconfiguration in question and for any ensuing changes.

···

Variables are crucial to IaC’s modularity and variable evaluation is essential to successful static analysis of it. With variable rendering support in Checkov, you can now analyze a misconfiguration even if it was sourced in a parameter that was defined on a different code block, ensuring that no risk goes unidentified.

Variable evaluation is available from Checkov version 1.0.641 and above. Our reimagined Resource Explorer with ideal fix locations and resource dependencies is also live in the Bridgecrew platform! Sign up for a free account and join in on the conversation on Slack.