Handling Sensitive Values in State
Many organizations use Terraform to manage their entire infrastructure, and it's inevitable that sensitive information will find its way into Terraform in these circumstances. There are a couple of recommended approaches for managing sensitive state in Terraform.
When working with a field that contains information likely to be considered
sensitive, it is best to enable the sensitive flag on the schema of that field using the SDK the provider is written in.
For example, the
Sensitive flag in Plugin Framework or the
Sensitive flag in SDKv2. This will prevent the field's values from
showing up in CLI output and in Terraform Cloud. It will not encrypt or obscure
the value in the state, however.
One experiment that has been attempted is allowing the user to provide a PGP key and a cipher text, and decrypting the value in the provider code before using it, storing only the cipher text in state. Another variation on this approach was providing a PGP key that data from an API would be encrypted with before being set in state, with nothing being set in the config.
Both of these approaches are discouraged and will be removed from the
HashiCorp-supported providers over time. This strategy was tailored to a time
when Terraform's state had to be stored in cleartext on any machine running
terraform apply, and was meant to provide a bit of security in that scenario.
With the introduction and use of
and especially the availability of
Terraform Cloud, there are now a variety of
backends that will encrypt state at rest and will not store the state in
cleartext on machines running
terraform apply. This means the original
problem the PGP key pattern was intended to solve has a better-supported
solution, and we're deprecating it in favor of that solution.
Even without comparing it to full state encryption, PGP key encryption has major drawbacks. Values encrypted with a PGP key can't be reliably interpolated, Terraform isn't built to provide a good user experience around a missing PGP key right now, and the approach needs serious modification to not violate protocol requirements for Terraform 0.12 and into the future.
In light of these shortcomings, the encouraged solution at this time is to use a state backend that supports operations and encryption, and for users whose security needs cannot be met by that strategy to weigh in on the issue about this to help outline the gaps in this strategy, so appropriate solutions can be designed for them.