terraform-provider-google: Don't store SSL private_key in the tfstate file

Thank you for the amazing software

Terraform Version

Terraform v0.11.1

Affected Resource(s)

google_compute_ssl_certificate

If this issue appears to affect multiple resources, it may be an issue with Terraform’s core, so please mention this.

Terraform Configuration Files

resource "google_compute_ssl_certificate" "default" {
  name_prefix = "my-certificate-"
  description = "a description"
  private_key = "${file("path/to/private.key")}"
  certificate = "${file("path/to/certificate.crt")}"
}

Expected Behavior

The private key should not show up in tfstate

Actual Behavior

It did

Steps to Reproduce

terraform apply

Possible solution

Store hash of the key instead of complete key, like we do for google_storage_bucket_object

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 16 (12 by maintainers)

Most upvoted comments

@paddycarver I agree that state is generally sensitive, but in this case I think there’s value in having an additional layer of protection. In particular, I often see developers having access to read the state bucket so they can develop Terraform config but that doesn’t mean they should have access to read the cert contents after it has been uploaded.

Importantly, the underlying API is specifically designed to not allow reading back the SSL cert key contents. I feel like Terraform should try to be as secure as the underlying API and not require that either. We already have pgp_key functionality on other resources, so would like to have some sort of equivalent here (or store the hash).

morgante on Jul 6, 2018

This should be resolved by GoogleCloudPlatform/magic-modules#1336.

paddycarver on Feb 1, 2019

Importantly, the underlying API is specifically designed to not allow reading back the SSL cert key contents. I feel like Terraform should try to be as secure as the underlying API and not require that either.

I think that’s fair.

We already have pgp_key functionality on other resources, so would like to have some sort of equivalent here (or store the hash).

I’d be game for only storing the hash if we can determine it doesn’t break existing use cases. What I think it’s harder to sell me on is functionality like pgp_key, which is more complicated, fragile, may not achieve the desired result, and ultimately requires giving the developer access to the sensitive information anyways, albeit with more of an annoying process to get it. (They still need to have the key available to them, IIUC, or Terraform will claim there’s a change. And if Terraform has the key to decrypt the information, the user has the information, and can get to the key.)

paddycarver on Jul 6, 2018