Terraform 0.14 allows users to define values as “sensitive,” making it easier to redact sensitive information in Terraform workflows.
We’re excited to announce that Terraform 0.14 includes the ability to thread the notion of a “sensitive value” throughout Terraform. In this first release along the lines of these new capabilities, we’ve focused on input variables & module outputs first, with an additional opt-in experiment for values which provider schemas mark as sensitive.
Starting with Terraform 0.14, input variable values can be defined as “sensitive”. Defining an input variable value as “sensitive” will result in Terraform redacting that value from CLI output. The same is true for module outputs. Module outputs with the sensitive=true
attribute set will also see their values redacted throughout a Terraform plan.
Sensitive values are still recorded in the state, and so will be visible to anyone who is able to access the state data. For more information, see Sensitive Data in State.
You can define a variable as sensitive by setting the sensitive argument to true:
Using this variable throughout your configuration will obfuscate the value from display in plan
or apply
output:
In some cases where a sensitive variable is used in a nested block, the whole block can be redacted. This happens with resources that can have multiple blocks of the same type, where the values must be unique. This looks like:
Terraform configuration:
Terraform CLI output:
Another important addition in Terraform 0.14 is that defining a module output as “sensitive” imparts the same behavior for those outputs as with variables defined as “sensitive”; those output values will be redacted even if they are consumed elsewhere in the Terraform plan. For more information on how a sensitive value can be manipulated via module outputs please see our updated documentation.
Terraform 0.14 also gives you the ability to expand upon values which the provider schema defines as “sensitive”. This existing feature prevents the value of that attribute from being displayed in logs or regular output. Terraform 0.14 extends this functionality by also propagating the sensitive mark through the plan.
In order to take advantage of the provider-specific sensitive attributes (those the providers define themselves), we’re asking our practitioners to opt-in to provider-schema sensitivity behavior. This new behavior may introduce redacted values in areas where such values aren’t expected by the end user, particularly where it comes to module outputs which may not have been explicitly set with a sensitive=true
attribute. In order to give our community time to understand and experiment with this new behavior, it needs to be enabled for each module where the behavior is desired.
To experiment with provider-based sensitive values, enable the experimental feature by adding the following terraform block to any module being used to evaluate the behavior:
We have many resources available for 0.14 for new and existing users. To learn more about the new functionality of 0.14 you can:
To get started using 0.14:
For more details, please see the full changelog. This release also includes a number of code contributions from the community and wouldn't have been possible without all of the great community feedback we've received via GitHub issues and elsewhere. Thank you!
HashiCorp Terraform 0.14 is the next step on our way to solidifying the Terraform ecosystem and empowering collaborative workflows at organizations of all sizes. You can download Terraform 0.14 here and sign up for a Terraform Cloud account here.
Terraform Enterprise now supports more flexible deployment options for self-hosted environments, including cloud-managed Kubernetes services.
Assigning agents at the organization level provides a faster, more consistent, and scalable approach to agent pool configuration.
Learn how creating a golden image pipeline can help unify and streamline your imaging and provisioning workflows throughout your infrastructure estate.