Flagging input variables are sensitive

[davidvuong]

Terraform Version

Terraform v0.10.5

I think being able to flag input variables as sensitive so terraform plan omits them is very useful. I wasn't sure if this was something others have mentioned but perhaps something like:

variables "sensitive_data" {
  default = ""
  description = ""
  type = ""
  sensitive = true
}

would be perfect.

I was using 0.9.10 and recently upgraded to 0.10.5. Previously, I would see <computed> everywhere but it seems changes have improved the plan command quite a bit. Unfortunately, for me, it now displays sensitive data.

[apparentlymart]

Hi @davidvuong!

From your message it first sounded like this was a feature request but the part at the end makes me suspect that you've seen a change in behavior between 0.9.10 and 0.10.5 with regard to sensitive value handling.

Although the plan display format has changed recently, the <sensitive> marker on resource attributes that are marked as sensitive is supposed to still be working. If you've found a case where something was marked as <sensitive> on 0.9.10 but is no longer doing so on 0.10.5 then that's a regression we should get fixed immediately... if you can share some more info (obviously, without actually sharing your sensitive details) that'd be awesome.

---

Regarding the feature request of marking variables as sensitive: variables don't directly appear in the plan output, so just adding that argument to the declaration would not really change anything. However, I think what you are asking for here is for Terraform to track "sensitive-ness" through interpolations, so for example if you were to write:

    foo = "baz ${var.sensitive_data} bar"

...Terraform should ideally notice that this foo argument was derived from a sensitive variable and thus treat the foo value as sensitive too.

If so, this is indeed something we would like to support. The current way interpolations are handled does not lend itself well to this unfortunately, but we're getting started on a revamp of how Terraform deals with configuration and interpolation which should leave us in a better spot to be able to do this sort of analysis. This is not something we can support in the near future, but is something we're making steps towards.

[davidvuong]

Hey, thanks for replying.

I haven't tested this but I can imagine <sensitive> would still be shown in places like the password field in the aws_db_instance resource so I suppose this is more of a feature request.

Example:

+ lambda
      id:                                                 <computed>
      arn:                                                <computed>
      description:                                        "xxx
      environment.#:                                      "xxx"
      environment.0.variables.%:                          "xxx"
      environment.0.variables.DATABASE_HOST:              "xxx"
      environment.0.variables.DATABASE_NAME:              "xxx"
      environment.0.variables.DATABASE_PASSWORD:          "xxx"
      environment.0.variables.DATABASE_PORT:              "xxx"
      environment.0.variables.DATABASE_USER:              "xxx"
      function_name:                                      "xxx"
      handler:                                            "xxx"
      invoke_arn:                                         <computed>
      last_modified:                                      <computed>
      memory_size:                                        "xxx"
      publish:                                            "xxx"
      qualified_arn:                                      <computed>
      role:                                               "xxx"
      runtime:                                            "xxx"
      s3_bucket:                                          "xxx"
      s3_key:                                             "xxx"
      source_code_hash:                                   <computed>
      timeout:                                            "xxx"
      tracing_config.#:                                   <computed>
      version:                                            <computed>
      vpc_config.0.vpc_id:                                <computed>

Environment variables passed into a lambda function have their value displayed as plain text.

Any idea when this might be something considered in a future version or perhaps workarounds to avoid this problem?

Thanks

[apparentlymart]

Hi @davidvuong,

Unfortunately aside from describing what we're currently working on (or not working on) we can't comment on specific schedules since our planning methodology is iterative. I can tell you that we are working on the foundational configuration language changes right now but we don't know at this time how long it will take to get all of the architectural changes we need in order for Terraform to be able to trace sensitive values through config -- it requires many more parts of Terraform to be aware of this concept than is true today.

---

Although I expect this isn't the sort of workaround you had in mind, please note that AWS does not generally recommended including secrets directly in Lambda environment variables since they can be accessed by anyone with permissions for the ListFunctions and/or GetFunction actions. Instead, they recommend to encrypt secrets using the Key Management Service (KMS) and then decrypt them inside the lambda function.

There is a guide for this in the AWS Lambda documentation. The AWS console integrates directly with KMS to make encryption easy, but unfortunately for Terraform this must be done out-of-band, e.g. using the KMS CLI. With that done, what would appear in the diff would then be the ciphertext rather than the the cleartext secret.

Unfortunately at this time the AWS provider doesn't have a good solution for producing such ciphertext on the fly, but in principle it could be extended with a new resource that takes some plaintext (marked as <sensitive> so it would not display in the diff) and uses a KMS key to produce a ciphertext that could then be interpolated into the Lambda function definition. (hashicorp/terraform-provider-aws#960 discusses why the existing KMS ciphertext data source is not suitable for this sort of usage.)

[johanot]

@apparentlymart Here's another use-case: We use the vsphere provider, and it requires username and password. I could go with sticking my password temporarily in the environment using VSPHERE_PASSWORD, but that would make my password readable in /proc for the entirety of the Terraform execution. I'd much prefer if Terraform could prompt me for my password and keep it only in memory as long as needed.

The way I see it, the experience could be improved with sensitive input variables as a generic solution. Or with a new variable type "password" (or similar) as a more narrow solution to this specific problem.

[umangdhaw]

I'm facing the same issue where the environment variables for lambda show up in plain text when I run terraform plan. Is there anything I can do to avoid that?

[stpierre]

AWS does not generally recommended including secrets directly in Lambda environment variables since they can be accessed by anyone with permissions for the ListFunctions and/or GetFunction actions. Instead, they recommend to encrypt secrets using the Key Management Service (KMS) and then decrypt them inside the lambda function.

This no longer appears to be the case; that page now merely presents that as a co-equal option:

Lambda stores environment variables securely by encrypting them at rest. You can configure Lambda to use a different encryption key, encrypt environment variable values client-side, or set environment variables in a AWS CloudFormation with AWS Secrets Manager.

So this looks like a well-supported use case, but Terraform (0.11 at least) still dumps Lambda environment variable values to the plan.

[apparentlymart]

Until such time as Terraform is able to do detailed tracing of propagation of sensitive values through expressions (which is still not something there is a ready-to-implement design for), the best answer to hiding sensitive values in the plan output would be to have the AWS provider include an argument marked as sensitive.

Since the environment variables is likely to be a mixture of sensitive and non-sensitive values in a single argument that would unfortunately likely require marking that whole map as sensitive, unless there's some signal from the AWS API that would allow the AWS provider to split the variables across two arguments, with one marked as sensitive and the other not.

It looks like there's already a proposal open for something like this in the AWS provider repository: hashicorp/terraform-provider-aws#11595. I'd suggest following that to see if it leads to a more straightforward answer for AWS Lambda specifically in the short term.

[skasukur]

Really surprised to see this issue open for so long. I also have same issue where i need to pass license keys to userdata scripts as variables. All our terraform pipelines are run on Jenkins, right now i am not printing the plan or apply logs to stdout instead redirecting to a file.

[Marcus-James-Adams]

I see lots of ideas of how to get around this for specific providers and functions, however it would be good I believe if this could bet set at a global scale independent of the provider.

For me it would be good if we could have something generic like

variable "myvariable" {
default = "this should be hidden in plans and outputs"
sensitive = true
}

[robcxyz]

Note that it seems a PR was recently merged to support this though it hasn't shown up in the release comments yet.
terraform/pull/26183.

Edit: Seems like they are targeting this for the 0.14 release.

[pselle]

Defining input variables as sensitive in order to redact the values from UI output is now available in 0.14! A recent blog post has more information on this feature, and I'll be closing this one as a result!

[ghost]

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.