Remote backend support encryption for all

[DblK]

Current Terraform Version

Terraform v1.1.9
on darwin_amd64

Use-cases

I use terraform to spawn my infrastructure and there are some data that are simple text in the state and can be credentials or other secrets.
I wanted to have all sensitive information not displayed in cli (use of sensitive property on output) but also in the state and still being usable!

Attempted Solutions

One approach could be to use remote backend but not all backend supports encryption and especially local which is the default one.
This reduce the choices to where to store state based on encryption criteria.

Proposal

It would be great to add options to encrypt state entirely or partially (sensitive output) by adding parameters to remote_backend regardless the backend chosen.

Something like this

data "terraform_remote_state" "foo" {
  backend = "gcs/local/whatever"
  config = {
    # Specific properties (here gcs example)
    bucket  = "terraform-state"
    prefix  = "prod"

    # Generic properties
    encrypt_state = true
    encrypt_privateKey = "..."
    encrypt_publicKey = "..."
  }
}

This will also solve the Security Notice on tls_private_key while encrypting state file and so generated private keys.

References

Not found

[apparentlymart]

Hi @DblK! Thanks for sharing this use-case.

I think you might be proposing something similar here to what I proposed in #9556. This is an example of an awkward genre of issue where I opened it before I was employed by HashiCorp and so it's a proposal on behalf of my old employer 😬 but I think it has similar underlying motivations, even though the details are a bit different.

The main blocking design questions across all of these variations of "storing sensitive data in the state" proposals is what Terraform ought to do in situations where you don't have the key. In this particular variant where the entire state is encrypted together, the terraform_remote_state data source effectively becomes useless unless you broadly distribute your private key, which I think most would consider unacceptable from a threat modelling standpoint.

Other variants call for encrypting different subsets of the state data which can therefore potentially allow some use of Terraform in situations where the key isn't known, but it's not clear yet what the right tradeoff is.

For now, the advice (which you've already seen) is to select a storage backend which supports encryption itself if you intend to store sensitive values in state. That has its own drawbacks -- it means anyone with access to the credentials needed to talk to the backend always has access to the entire state, as above -- but those problems effectively exist outside of Terraform rather than inside it, and so can be addressed (in part) with techniques such as short-lived credentials.

[kayrus]

@apparentlymart from my understanding, implementing the pluggable backends would allow to fix sensitive values at the first place: #5877