Terraform: We are seeing secret keys leaks in terraform plan

[marcb1]

Hi there,

We have been working extensively with the Fastly terraform plugin, and I suspect we hit a terraform bug after planning many Fastly services.

The Fastly HCL, has a gcslogging block, which contains some parameters, once of which is secret_key. This is marked as Sensitive: true: https://github.com/terraform-providers/terraform-provider-fastly/blob/7fd4be916ef719fe41179b678bc538e34dea824a/fastly/resource_fastly_service_v1.go#L824-L829

Every once in a while, we will see the entire key, leaked in the terraform output:

gcslogging.1621793657.secret_key:         "\n-----BEGIN PRIVATE KEY-----\n...

We don't think this is a bug in the provider, as they have correctly marked the value as sensitive, yet terraform still displays it.

$ terraform -v
Terraform v0.11.11
+ provider.fastly v0.5.0
+ provider.vault v1.4.1

Terraform Configuration Files

  gcslogging {
    bucket_name        = "logs-fastly"
    email              = "[email protected]"
    format             = "%h %l %u %t \"%r\" %\u003es %b"
    gzip_level         = "9"
    message_type       = "classic"
    name               = "-logs-fastly"
    path               = "/fastly/%Y-%m-%d/"
    period             = "3600"
    secret_key         = "${trimspace("${data.vault_generic_secret.private-key.data["value"]}")}"
    timestamp_format   = "%Y-%m-%dT%H:%M:%S.000"
  }

Steps to Reproduce

We are adding a new service to the terraform state file and creating a new HCL file to match the service

1. terraform init
2. create HCL file, with some value that should be marked sensitive see, gcslogging HCL above
3. terraform import, service to update the state file.
4. terraform plan

The plan will show some diffs, and will leak the secret key!

[rmb938]

I am also seeing a similar issue see https://github.com/terraform-providers/terraform-provider-helm/issues/251

[apparentlymart]

In Terraform v0.11 it is the responsibility of the provider (in this case, the shared SDK code as opposed to the provider-specific code) to mark attributes as sensitive when the plan is produced, because Terraform Core itself cannot see the schema and thus know when something is sensitive. I suspect there is a bug in that logic in the SDK that is failing to honor the setting properly when an attribute is nested inside a TypeSet block.

The architecture has changed for v0.12 so that providers instead report their schema to Terraform Core and then Terraform Core itself can detect when something is sensitive and handle the hiding of it in the plan output in a standard way. Because Terraform Core approaches that problem in quite a different way than the SDK did for v0.11, I suspect this behavior is already better in the master branch for Terraform v0.12, but we'll need to verify that against a build of the Fastly provider (or Helm provider) that supports the new provider plugin protocol for Terraform v0.12.

[hashibot]

Hello! :robot:

This issue relates to an older version of Terraform that is no longer in active development, and because the area of Terraform it relates to has changed significantly since the issue was opened we suspect that the issue is either fixed or that the circumstances around it have changed enough that we'd need an updated issue report in order to reproduce and address it.

If you're still seeing this or a similar issue in the latest version of Terraform, please do feel free to open a new bug report! Please be sure to include all of the information requested in the template, even if it might seem redundant with the information already shared in _this_ issue, because the internal details relating to this problem are likely to be different in the current version of Terraform.

Thanks!

[hashibot[bot]]

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.