Skip to main content
Terraform Integrations

Learn about our flexible low-code integration type that collects evidence from common cloud platforms and services

Micah Spieler avatar
Written by Micah Spieler
Updated over a week ago

Collecting evidence of your controls operating as designed is one of the key ways that you can ensure that you maintain a state of compliance, as well as continuously prepare for your next audit event.

Strike Graph's Terraform integrations allow you to use a low-code solution to collect evidence from your infrastructure and DevOps systems. These integrations are built on the back of Terraform, an industry-leading infrastructure-as-code solution, but they do not require you to utilize Terraform yourself in your tech stack.

Like all of our integrations, Terraform integrations come with two components:

  • Integration Manager configurations where you set up the permissions necessary to authorize Strike Graph to collect evidence from your systems. Strike Graph only requires (and also recommends) read-only access, meaning that your data and systems remain secure.

  • Evidence Collection & Automated Collection configurations where you link your integration with evidence objects and define what (and how frequently) you would like Strike Graph to collect evidence.

Terraform integrations are unique in that they provide a flexible, user-friendly interface for defining what you would like to collect as evidence. Using Terraform and their HCL syntax and a few lines of code, you can configure evidence collection (with automation) of almost any resource from supported cloud providers.

Configuring Terraform integrations

Each Terraform provider requires different authentication methods to allow Strike Graph read-only access to the data provided by that system. Follow the guides for the specific providers for details on how to configure the Terraform integration for that system:

Using Terraform integrations to collect evidence attachments

After you have a Terraform integration configured, you then get to define the evidence that you would like to collect. To get started, open the evidence object that you would like to add an attachment (or automation) to.

Once you have the evidence object that you would like to collect an attachment for, select either direct attachment (for a one time pull) or automated collection (our recommendation for Terraform integrations). Learn how to configure automated collection, or adjust the expiration schedule to tailor how often evidence is automatically recollected.

Basic components of Terraform evidence collection

The Terraform evidence integrations have two basic parts, a data block (that defines what data source you will collect from, including any required query constraints or attributes), and a local value (which defines the evidence you want to collect from the data source).

Step 1: Define the data block

A data block is a declaration that directs Strike Graph's evidence collectors to read information from supported data sources (for example "AWS IAM"), and then export the results under a temporary name. Strike Graph uses Terraform as an underlying technology to power these requests, so the supported data sources are aligned with their vast libraries of supported data sources per provider.

Screenshot showing the Cumulus evidence collection interface in Strike Graph, specifically the data block definition

The Strike Graph interface acts as an easy guide to define the following components of the data block:

data_source – The data source is the Terraform provider data resource that you would like to collect from. Different from managed resources, data sources only allow read arguments, and do not create, delete, or modify resources. For more information on which data sources are available, check out the information for your specific cloud system provider.

temp_name – This temporary name is used to refer to this data block during execution, and only has labeling significance within the scope of this configuration. Some things to keep in mind:

  • The temp name is used in the output's filename for reference during the audit export process.

  • It's recommended that you name it with something recognizable.

  • Names can be repeated across configurations, are limited to alphanumeric characters and do not allow spaces.

query constraints / attribute arguments – Many data sources require specific attribute(s) to be included (like the name of the resource you're pulling data from), or provide methods for constraining the data based on specific queries so that you can tailor the output. These are written as a key/value pairs and can include multiple arguments as accepted by the data source.

Putting it all together...

Here is an example data block that would output a list of IAM roles from AWS that match a certain regex pattern. It would be collected under a file named with “aws_iam_roles-example”.

data "aws_iam_roles" "example" {
name_regex = "Admin*"
}

Step 2: Define the local values

Locals provide temporary reference values to the information being requested in the data block. For more information on HCL local values, Terraform's website has helpful information.

Screenshot showing the Cumulus evidence collection interface in Strike Graph, specifically the local values definition

Local values tend to follow this specific pattern:

data.data_source.temp_name

data – Most of the time, local values start with "data".

data_source – Include the data_source that you defined in the data block above.

temp_name – Include the temp_name that you defined in the data block above.

keys – Keys are very optional and usually not recommended. You can define a key at the end of your local value reference to further restrict the data request if desired.

Putting it all together...

Here is an example of local values that would correspond to the data block identified above for a list of IAM roles from AWS. In this example, there are no keys defined.

data.aws_iam_roles.example

Data collection

Once the data block and local values are defined and submitted, Strike Graph uses this information to collect the necessary evidence attachment. This may take a minute to complete, but once it is complete you can view the information collected by clicking on the evidence attachment.

The data collected is stored as JSON, and maybe be lightly formatted to make it more human readable.

I got an error! What should I do?

Errors happen, and hopefully we can help you resolve them.

Check permissions

If you run into an error while trying to set up a Terraform integration, the first thing to check is that you have given Strike Graph the necessary read-only permissions to collect data from the resource that you defined in the data_source section of the data block.

Review the error message

We return the error message that we receive during collection. It typically identifies where the issue is in the data block or local values. Some common issues:

  • If the message returned is pretty generic (like "Something went wrong") it may be a formatting issue. Check that your temp_name is formatted correctly (no spaces, only alphanumeric characters) and that there are not any other unexpected characters or formatting issues in the data block or local values.

  • Check that the resource you defined in the data_source is available from the cloud system provider you're requesting from. You can refer to this list of providers from Terraform for supported data_sources.

  • Confirm the details of the query constraints / attribute arguments. Check that you have properly identified the resource names (if included) and that there are no errors.

  • Check that the data_source and temp_name values are the same between the data block and local values.

  • Confirm that the local values is formatted correctly. Typically, the local value should start with "data" (as described above) and include the data_source and temp_name.

If these tips don't help, send us a message via the Messenger chat and we'll do what we can to help troubleshoot.

Did this answer your question?