Why does Terraform plan output show tfe_variable value as (sensitive value)

Terraform HCP Terraform
1

Why does Terraform Plan ~ update in-place show a non sensitive variables as (sensitive value)

------------------------------------------------------------------------

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # tfe_variable.storage_tf_vars["my-workspace.my_config"] will be updated in-place
  ~ resource "tfe_variable" "storage_tf_vars" {
        category     = "terraform"
        hcl          = false
        id           = "var-123456789"
        key          = "my_config"
        sensitive    = false
      ~ value        = (sensitive value)
        workspace_id = "ws-123456789"
    }

Is there anyway to tell Terraform Plan to show the actual change being made to non sensitive variables?

2

I’d like to know the same for aws_ssm_parameter resource. Value in question is a String, SecureString should stay hidden.

I’m using TF v0.12.20 if that helps.

3

You cannot show secret values (either attribute set as sensitive by the provider, or variables or outputs which are declared as secret in the configuration) in the UI, but they are still encoded in the plan (or statefile).

One way to see the full change, including any secrets, is to output the plan to a file and inspect that.

Here’s an example configuration with a (user-defined) sensitive value:

variable "sensitive" {
  default = "secret"
  sensitive = true
}

resource "random_pet" "secret" {
  prefix = var.sensitive
}

now I run terraform plan, and save the plan to a file called tf.plan:

terraform plan -out tf.plan

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # random_pet.secret will be created
  + resource "random_pet" "secret" {
      + id        = (known after apply)
      + length    = 2
      + prefix    = (sensitive)
      + separator = "-"
    }

Plan: 1 to add, 0 to change, 0 to destroy.

------------------------------------------------------------------------

This plan was saved to: tf.plan

To perform exactly these actions, run the following command to apply:
    terraform apply "tf.plan"

And then I’ll use terraform show -json to see the full plan, including that sensitive prefix (this is a small snippet of the output, piped through jq for pretty printing):

terraform show -json tf.plan | jq
{
   /// truncated output
     "planned_values": {
    "root_module": {
      "resources": [
        {
          "address": "random_pet.secret",
          "mode": "managed",
          "type": "random_pet",
          "name": "secret",
          "provider_name": "registry.terraform.io/hashicorp/random",
          "schema_version": 0,
          "values": {
            "keepers": null,
            "length": 2,
            "prefix": "secret",
            "separator": "-"
          }
        }
      ]
    }
  },
}

terraform show -json also lets you examine the contents of statefiles, not just plans.

4

That won’t work for Terraform Cloud however.

Error: Saving a generated plan is currently not supported

The "remote" backend does not support saving the generated execution plan
locally at this time.

I still don’t understand why tfe_variable with sensitive = false doesn’t show in the plan?

5

Hi @deasunk,

If your motivation here is just to understand why it behaves the way it does then I can at least help with that: the idea of resource type attributes being sensitive is a static, schema-level thing defined by the provider, rather than something decided dynamically at runtime. The “tfe” provider therefore has that attribute marked as Sensitive because it can potentially be sensitive. The only alternative within Terraform’s architecture today would be for it to not be marked as sensitive at all, which would then expose it even when sensitive = true.

2 Likes
6

Hi! Just to elaborate a bit more on @apparentlymart’s correct answer:

I think there’s two major bits of confusion here:

So, with all of the “how” bits sorted out…Why do the providers mark these values as sensitive in their schemas?

The value is marked as sensitive (statically, via the schema) because the value is still returned on initial creation and stored in state, and since it may be marked as a sensitive value by the platform, the provider opts to play it safe and avoid any chance of exposing it, given that possibility.

1 Like