Option to hide sensitive info in state

[yzargari]

Current Terraform Version

Terraform v0.12.12

Use-cases

I use terraform to provision many different types of resources. Some will take sensitive details (tokens, keys, etc) as input and some will create sensitive details as output and store them in tfstate, which in some cases isn't desired.

Attempted Solutions

Input fields could partially be worked around if you set a bogus value and define the resources to ignore change to that field (but the real value could still appear in the tfstate file) - but there isn't a real good solution to hiding sensitive date.

Proposal

I believe adding a configuration similar to ignore_changes, to list the attributes which should not be stored in state. Perhaps that could somehow interchange with ignore_changes (maybe even use the same config).

[nbering]

It's up to the individual providers to decide what they store. You can flag an "output" as sensitive, and it will not displayed at the end of the run (but it will still be stored in state).

Providers can also declare resource attributes to be sensitive.

terraform/helper/schema/core_schema.go

Line 123 in e32641c

Sensitive: s.Sensitive,

But again, this only has an effect on logging, and not on state file itself.

The AWS provider makes use of a helper to encrypt values in state in a few places, but then you need to decrypt them with your private key before you can use them.... and they cannot be used directly by other resources.

As a user, I personally feel that reasonable effort has been made to keep secrets secret - and there could be some improvement. But having dug through the architecture a bit myself, I respect that it's a significant challenge to provide the core functionality that Terraform offers, and also omit certain details from state at will.

[yzargari]

Thanks for your input @nbering

I do realize that provider can decide what they store and what they don't - but I also think there's a lot of room for different users/use-cases have different requirements.
For instance, I'm using the pagerduty provider to provision services and service extension, which creates integration keys. Some users would be happy to reference the integration keys in other resources that may need it - but if you don't need it, there's no point in saving it in the state.

[romaninsh]

Re: how to implement: SSM store, that may provide sensitive data has support for versions. Instead of storing sensitive value, perhaps it's version (or md5) can be stored. Then on the next run - we could check if version has changed or if md5 has changed in which case request sensitive value, pass it on to the destination.

[pkolyvas]

@yzargari Thanks for your thoughtful contribution. There are a number of other issues following similar discussions:

• Storing sensitive values in state files #516
• Feature request: ability to configure variables to mask in the output of terraform plan #16554
• local-exec provisioner: suppress sensitive output #17568
• Provide a sensitive attribute to Variables #18692

This list isn't comprehensive, but managing sensitive values is something we're very much thinking about. In the near term it's unlikely we'll do any work within the state file as we have other priorities, but it is on our radar.

At the moment, our point of view is that the state itself is sensitive and should be treated like any sensitive value. We realize this isn't acceptable or adequate for all workflows as you've clearly noted.

I am going to close this issue as a duplicate, but I've logged it as reference point for us as we begin to chart out our course.

Duplicate of #516

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