Terraform: Variable/output hiding

[geovanisouza92]

If the terraform plan/apply runs on CI/CD, the logs could be stored, causing secret leaks.

I suggest to make variable blocks support a hidden argument, of type bool (default: false), to allow us to hide variable/output values from leaking on stdout and (maybe) *.tfstate files.

variable "password" {
  default = "supersecret"
  hidden = true
}

Then:

<resource>.<name>:
  password = "<hidden>"

[jen20]

Hi @geovanisouza92! There has been a long running discussion about this over at https://github.com/hashicorp/terraform/issues/516 - it's on our roadmap to investigate.

To address your suggestion specifically: I do like the idea of being able to mark individual variables as "sensitive" (in a similar manner to what Travis CI does with encrypted variables, for example), but I'm not sure it would be sufficient to hide just the variables without tracking their provenance through the entire configuration and display. Imagine the following configuration:

provider "aws" {
    region = "us-west-2"
}

variable "topsecret" {
    default = "this shouldn't be exposed"
}

resource "aws_vpc" "test_vpc" {
    cidr_block = "10.0.0.0/16"

    tags {
        Name = "${var.topsecret}"
    }
}

The output from terraform plan is:

+ aws_vpc.test_vpc
    cidr_block:                "" => "10.0.0.0/16"
    default_network_acl_id:    "" => "<computed>"
    default_security_group_id: "" => "<computed>"
    dhcp_options_id:           "" => "<computed>"
    enable_classiclink:        "" => "<computed>"
    enable_dns_hostnames:      "" => "<computed>"
    enable_dns_support:        "" => "<computed>"
    main_route_table_id:       "" => "<computed>"
    tags.#:                    "" => "1"
    tags.Name:                 "" => "this shouldn't be exposed"

Ignoring the obvious stupidity of using a secret as the tagged name of a VPC (!), this would be the same for any use of the variables and there is no good way to track their provenance through to display right now in order to elide them.

That said, this is valuable input that I'd like to fold into #516 so that we can reference it when designing a solution to this. Thanks for opening the issue!

[SpamapS]

Wow maybe reconsider lumping state with logging/output and consider opening it and solving separately. This is entirely different IMO. It's really hard to police log files for passwords, and it has very little to do with state files.

[sjungwirth]

for anyone coming across this from google, there is now a sensitive attribute that you can add to outputs: https://www.terraform.io/docs/configuration/outputs.html#sensitive-outputs

output "example" {
  value     = "..."
  sensitive = true
}

Note that this is mostly useful in the CI scenario as anyone with access to the state can always terraform output or read it directly.

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.