HMAC Key/ServiceAccount Key Data field is declared sensitive (but maybe should not be?)

[huang-jy]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request.
• Please do not leave +1 or me too comments, they generate extra noise for issue followers and do not help prioritize the request.
• If you are interested in working on this issue or have submitted a pull request, please leave a comment.
• If an issue is assigned to the modular-magician user, it is either in the process of being autogenerated, or is planned to be autogenerated soon. If an issue is assigned to a user, that user is claiming responsibility for the issue. If an issue is assigned to hashibot, a community member has claimed the issue already.

Terraform Version

0.15.0

Affected Resource(s)

• provider registry.terraform.io/hashicorp/google v3.64.0
• provider registry.terraform.io/hashicorp/google-beta v3.64.0
• provider registry.terraform.io/hashicorp/random v3.1.0

Terraform Configuration Files

resource "google_service_account" "test-sa" {
  account_id   = "test-sa"
  display_name = "Test ServiceAccount"
}

resource "google_project_iam_member" "test-sa-storage-admin" {
  role = "roles/storage.admin"
  # role   = "roles/storage.objectAdmin"
  member = "serviceAccount:${google_service_account.test-sa.email}"
}

resource "google_project_iam_member" "test-sa-workload_identity" {
  role   = "roles/iam.workloadIdentityUser"
  member = "serviceAccount:my-project.svc.id.goog[gke-namespace/gke-account]"
}

resource "google_service_account_key" "test-sa-key" {
  service_account_id = google_service_account.test-sa.name
  # public_key_type    = "TYPE_X509_PEM_FILE"
  public_key_type = "TYPE_RAW_PUBLIC_KEY"

  depends_on = [
    google_service_account.test-sa
  ]
}

resource "google_storage_hmac_key" "test-sa-hmac-key" {
  service_account_email = google_service_account.test-sa.email
  depends_on = [
    google_service_account.test-sa,
    google_project_iam_member.test-sa-storage-admin,
    google_project_iam_member.test-sa-workload_identity,
    google_service_account_key.test-sa-key,
    google_container_cluster.main-gke-cluster,
    google_container_node_pool.gke-cluster-nodes
  ]
}

output "test-sa-hmac-key-secret" {
  value     = google_storage_hmac_key.test-sa-hmac-key.secret
  sensitive = true
}

output "test-sa-hmac-key-access-id" {
  value = google_storage_hmac_key.test-sa-hmac-key.access_id
}

output "test-sa-private-key-data" {
  value     = base64decode(google_service_account_key.test-sa-key.private_key)
  sensitive = true
}

Debug Output

Available if required

Panic Output

N/A

Expected Behavior

HMAC key/ServiceAccount secret data output as per previous version

Actual Behavior

I used to use an older version of terraform (0.12.29) and when running this configuration on that version, I did not require the sensitive attribute on the secret key field.

I used to use the terraform output command to obtain values of the resources terraform created during the apply, including the secret value of the HMAC key as this is only available at the time of creation ( you cannot retrieve this information after the key is created ), and similarly with the ServiceAccount key -- you cannot retrieve the key data after you have created it.

However, with the newer version of Terraform (which presumably also grabs a later version of the provider), this field is now declared as sensitive, meaning I have to use sensitive = true in order for the apply to work. This also redacts the data on the output, and requesting the output of that field is no longer possible. Meaning I cannot use the HMAC key or ServiceAccount created by Terraform.

Yes, I could create the key and ServiceAccount outside of Terraform, but that means the state of the infrastructure has diverged from what is declared in the terraform files.

So the question is, is there another way I can retrieve this information from within Terraform, if I cannot retrieve the data via the terraform output command?

Steps to Reproduce

1. terraform plan -out tfplan
2. terraform apply tfplan

Important Factoids

N/A

References

[edwardmedia]

@huang-jy sensitive is a feature of Terraform core. Here is what its doc explains. You can see the changes from earlier versions. What you see appears to be by design. I am afraid we can do much at the provider level. Do you want to file an issue at their site?

[huang-jy]

Is the declaration of sensitive for a field defined at provider level or at core level? I would suspect provider level since other fields such as access_id is not declared as sensitive.

As it is right now, creating a HMAC key or GCP serviceaccount via Terraform on this provider version is almost pointless because you cannot get the secret data to use it effectively.

Admittedly for ServiceAccounts this actually might be fine, since you could use it via other means such as through Workflow Identity, but you would be unable to directly impersonate as that ServiceAccount unless you create a new key -- which defeats the object of using Terraform to create the ServiceAccount key in the first place, not to mention the infrastructure is now diverged from the Terraform definition.

If I force Terraform to use a version of the provider from before sensitive is used, I suspect this will work.

[huang-jy]

Ah, I think I have a (probably better) way of getting the data rather than using the output clause -- using the local_file clause instead

resource "local_file" "test_hmac_secret" {
  sensitive_content = google_storage_hmac_key.test-sa-hmac-key.secret
  filename          = "test-sa.hmac_secret"
}

This seems to work with the ServiceAccount secret key as well. So I will close this issue.

[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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 hashibot-feedback@hashicorp.com. Thanks!