We’ve previously discussed the syntax for creating variables within Terraform configuration. While this helps us with syntax, it leaves open questions about how variable values are actually passed into our Terraform workflow.

CLI Specification

When running terraform plan or terraform apply on the command line, we can add a “-var” flag and pass our variable names in that way. For example:

terraform {plan|apply} -var=”bucket_name=my-bucket-name-example”

 This, as you can imagine, does not scale very well when variables increase, and only really works for Terraform workflows that are being executed locally and with few input variables.

.tfvars File

You can also create a .tfvars file with many variable assignments in it. We can specify the exact file path to the .tfvars file with the following syntax:

terraform {plan|apply} -var-file=”my-var-file-prod.tfvars”

Or, Terraform will default try to load files named exactly terraform.tfvars, terraform.tfvars.json, or files ending with .auto.tfvars or .auto.tfvars.json.

This is much better for handling multiple variables at once, and you can create different .tfvars files for different environments (dev.tfvars, staging.tfvars, prod.tfvars, etc.). That being said, this solution can be problematic and require extra engineering work when running Terraform in remote, automated workflows. For example, if we are storing variables in a .tfvars file then our workflows will need to have that file in memory. Since variables often contain sensitive information, there is no easy way to protect sensitive information to high levels of security when using .tfvars files (internal users can access the files, and the variables can be visible on multi-tenant compute resources that run CI/CD jobs).

Environment Variables

Terraform will also read in variable values from environment variables. Any environment variable that is prefixed with TF_VAR_ will be read into Terraform. This can be advantageous from a security perspective because environment variables values can be securely stored and then injected into compute running a Terraform workflow. Of course, managing many environment variables at scale can become challenging.

Managed Solutions

HashiCorp’s Terraform Cloud solution supports secure, well integrated variable management for individual workspaces. Using Terraform Cloud’s variable sets, we can also create variables that are shared across multiple state files.

Better yet, all of these variables and variable sets can be managed using terraform itself! The tradeoff for being able to manage variables securely at scale is being tied to running Terraform workflows through Terraform cloud, which can become a rather expensive solution to use.

Choosing Your Solution

The size of your organization, where you run your Terraform workflows, your security requirements, and budget across both engineering time and dollars are all important factors to consider when deciding on a Terraform variable management strategy. We hope this discussion of different options and their pros and cons helps assist you as you decide what will be best for your organization. 

If you have any questions, please drop us a line!

dragondrop.cloud’s mission is to automate developer best practices while working with Infrastructure as Code. Our flagship product regularly scans and identifies resource changes that have occurred outside of a Terraform workflow (e.g. drift) so that dev teams can have a Cloud environment that is fully represented as code. All of our tools are self-hosted by our customers, with no data ever leaving their servers. To learn more, schedule a demo or get started today!

Your content goes here. Edit or remove this text inline or in the module Content settings. You can also style every aspect of this content in the module Design settings and even apply custom CSS to this text in the module Advanced settings.

Learn More About Terraform