terraform

Terraform 0.14 Adds the Ability to Redact Sensitive Values in Console Output

Terraform 0.14 allows users to define values as “sensitive,” making it easier to redact sensitive information in Terraform workflows.

Nov 11 2020Petros Kolyvas, Pam Selle

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:

variable "user_information" {
  type = object({
    name    = string
    address = string
  })
  sensitive = true
}
 
resource "some_resource" "a" {
  name    = var.user_information.name
  address = var.user_information.address
}

Using this variable throughout your configuration will obfuscate the value from display in plan or apply output:

Terraform will perform the following actions:
 
  # some_resource.a will be created
  + resource "some_resource" "a" {
      + name    = (sensitive)
      + address = (sensitive)
    }
 
Plan: 1 to add, 0 to change, 0 to destroy.

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:

# main.tf
 
resource "some_resource" "a" {
  nested_block {
    user_information  = var.user_information # a sensitive variable
    other_information = "not sensitive data"
  }
}

Terraform CLI output:

Terraform will perform the following actions:
 
  # some_resource.a will be updated in-place
  ~ resource "some_resource" "a" {
      ~ nested_block {
          # At least one attribute in this block is (or was) sensitive,
          # so its contents will not be displayed.
        }
    }

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.

»Enabling Provider-Schema-Based Sensitive Values

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:

terraform {
  experiments = [provider_sensitive_attrs]
}

»Getting Started

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:

  • Download the Terraform 0.14 release.
  • If you are upgrading from a previous release, read the upgrade guide to learn how to adopt Terraform’s new features.

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.

Sign up for the latest HashiCorp news

More blog posts like this one

Terraform Cloud adds new Sentinel policy review UI
March 16 2023 | Products & Technology
Terraform Cloud adds new Sentinel policy review UI

Introducing a more efficient, streamlined way of managing policy as code workflows in Terraform Cloud.

Dynamic provider credentials now generally available for Terraform Cloud
March 09 2023 | Products & Technology
Dynamic provider credentials now generally available for Terraform Cloud

Terraform’s dynamic provider credentials enable secure, short-lived authentication for HashiCorp Vault and cloud providers.

Terraform 1.4 improves the CLI experience for Terraform Cloud
March 08 2023 | Products & Technology
Terraform 1.4 improves the CLI experience for Terraform Cloud

Terraform 1.4 is now generally available, featuring enhanced run output in Terraform Cloud, support for OPA policy results in the CLI, and a native replacement for the null resource.