Terraform Variable Management
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 OSS product, cloud-concierge, allows developers to codify their cloud, detect drift, estimate cloud costs and security risks, and more — while delivering the results via a Pull Request. For enterprises running cloud-concierge at scale, we provide a management platform. To learn more, schedule a demo or get started today!
Learn More About Terraform
Everything Everywhere All as Code
“Everything as Code” Definition Everything as Code is a philosophy for managing IT infrastructure where all components of infrastructure are created, managed, and deleted using code. This applies to container definitions, cloud infrastructure, on-premise server...
Open Source driftctl Alternatives
What is driftctl? driftctl is an OSS CLI tool that enables users to identify Terraform drift as well as unmanaged resources within a cloud environment. It is a quite popular tool and has collected over two thousand stars on GitHub. Why Would We Want a Replacement?...
Why We Are Not Supporting OpenTF
Background On August 10, HashiCorp changed the license to their previously “Open Source” projects to a Business Source License (BSL), making them now “source available” for all future releases. We discusssed in detail reasons and motivations for this change here. On...