Feature Request: Ability to declare & mask sensitive data in the output of "terraform show" command.

[ashishth09]

We have a service wrapped around terraform and the users of the service don't have access to the state file. The service runs terraform show and displays all the info from the state file in some UI logs. We want a mechanism to allow writers of the tf file to specify which fields should be shown in the output of the command.

[davetropeano]

This request extends to ALL possible output paths of terraform -- logs and terraform show.

Right now, sensitive only applies to outputs... in order to close the SPI leakage we need to extend HCL/terraform to allow sensitive as a modifier for variables and then in the log output make sure we redact any variable values that are labeled as sensitive. Another option would be to force a variable naming convention where variables with a suffix like _spi are treated as sensitive and always have their values redacted in logs and state.

I realize it isn't quite that easy :) but am trying to point out the bigger picture of wanting to close all SPI leakages.

[apparentlymart]

Hi @ashishth09, @davetropeano,

Currently Terraform has a couple mechanisms for redacting sensitive information:

• The configuration author can mark an output as sensitive using sensitive = true
• A provider developer can mark a particular provider attribute as sensitive within the provider code, which then prevents it from showing in the UI.

In the short term, if you find a provider attribute that is documented as accepting or producing a secret and it doesn't appear as <sensitive> in the plan output, that's a bug in the provider and I'd encourage you to report it as such within the provider's own repository.

Currently these features are limited only to the "main workflow" (terraform plan, terraform apply) since this is the part that is documented for automation purposes. It's not technically possible right now to apply the <sensitive> redaction to all commands, since that information is not necessarily available. As a consequence, the output of terraform show should be treated as being just as sensitive as the state file itself: it's essentially just a pretty-printer for the raw state file, intended to help with debugging, rather than something we expect to be used regularly.

---

I understand that there is a subtlety here between what Terraform might consider "sensitive" (attributes that are documented as containing passwords, private keys, etc) and what a business might consider sensitive (personal information about individuals, account numbers that might be used to aid some other attack, etc). Terraform cannot currently model the latter, and will not be able to in the short term.

We have a longer-term plan to perform static analysis on interpolations within the configuration to infer when one value is derived from another value that is marked as sensitive, so the <sensitive> redaction can be applied transitively. Terraform's internals can't currently support this due to how values and expressions are represented, but the current work to revamp the configuration language is being done with this use-case in mind. This would also include a change like #16114 to allow inputs to be marked as sensitive, as a user-specified "root" of sensitivity that would then propagate through configuration.

It's not clear at this time whether terraform show in particular would be able to support such a thing, since it would need to be written in a very different way to be able to do this sort of analysis. In general I would strongly recommend that those automating Terraform stick to the core workflow commands that are documented for automation scenarios. There are other plans to make it possible to run Terraform without direct access to state (by delegating to a process on a remote system) but this will apply only to the core workflow commands (as documented on that page) for the foreseeable future.

[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.