Update support for PubSub Topic KMS key

[MikeMoore63]

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

Terraform v0.12.24

• provider.google v3.20.0

Affected Resource(s)

• google_pubsub_topic

Terraform Configuration Files

# Copy-paste your Terraform configurations here.
#
# For large Terraform configs, please use a service like Dropbox and share a link to the ZIP file.
# For security, you can also encrypt the files using our GPG public key:
#    https://www.hashicorp.com/security
#
# If reproducing the bug involves modifying the config file (e.g., apply a config,
# change a value, apply the config again, see the bug), then please include both:
# * the version of the config before the change, and
resource "google_pubsub_topic" "hgmsBucketUpload" {
  name = "hgmsBucketUpload${var.developer}"
  kms_key_name = "projects/${var.kmsproject}/locations/global/keyRings/pubSub/cryptoKeys/pubSub"
  message_storage_policy {
    allowed_persistence_regions = [
      "europe-west1",
      "europe-west2"
    ]
  }
}
# * the version of the config after the change.
resource "google_pubsub_topic" "hgmsBucketUpload" {
  name = "hgmsBucketUpload${var.developer}"
  kms_key_name = "projects/${var.kmsproject}/locations/europe/keyRings/pubSub/cryptoKeys/pubSub"
  message_storage_policy {
    allowed_persistence_regions = [
      "europe-west1",
      "europe-west2"
    ]
  }
}

### Debug Output

google_pubsub_topic.hgmsBucketUpload must be replaced

-/+ resource "google_pubsub_topic" "hgmsBucketUpload" {
~ id = "projects/methodical-bee-162815/topics/hgmsBucketUpload" -> (known after apply)
~ kms_key_name = "projects/methodical-bee-162815/locations/global/keyRings/pubSub/cryptoKeys/pubSub" -> "projects/methodical-bee-162815/locations/europe/keyRings/pubSub/cryptoKeys/pubSub" # forces replacement
- labels = {} -> null
name = "hgmsBucketUpload"
~ project = "methodical-bee-162815" -> (known after apply)
message_storage_policy {
allowed_persistence_regions = [
"europe-west1",
"europe-west2",
]
}
- timeouts {}
}

see output states km key forces replacement
The patch method here

https://cloud.google.com/pubsub/docs/reference/rest/v1/projects.topics/patch

how kms key can be patched and replacement is not required.

Panic Output

Expected Behavior

Should update topic in place

Actual Behavior

Terraform states change forces replacement so deletes topic potentially losing data and recreates

Steps to Reproduce

1. terraform apply cretae a topic with kms key
2. change terraform topic to to point at new key
3. terraform plan shows output

form plan then out put shows topic will be replaced not updated in place

Important Factoids

tested with both same behavior

References

• #0000

[edwardmedia]

I can see updating the location in below HCL will force all three resource recreation.

resource "google_pubsub_topic" "example" {
  name         = "issue6386topic"
  kms_key_name = google_kms_crypto_key.crypto_key.self_link
  message_storage_policy {
    allowed_persistence_regions = [
      "europe-west1",
      "europe-west2"
    ]
  }
}
resource "google_kms_crypto_key" "crypto_key" {
  name     = "issue6386key"
  key_ring = google_kms_key_ring.key_ring.self_link
}
resource "google_kms_key_ring" "key_ring" {
  name     = "issue6386keyring"
  location = "europe"  #### <----- updated location from global to europe
}

[MikeMoore63]

The key is in another project and we have segregated duties between those reponsible for kms admin so creation keyrings and keys vs those using the keys. So it cannot exist in my terraform it is just a reference in my case and the key exists already. So this IMHO is a completely different use case. With CMEK the account setting the key actually requires zero access to the key as that also would be against least privilege only the back end pubub cmek account requires access.

see this Security Health Analytics reccomendation as to why this is common and best practice.

https://cloud.google.com/security-command-center/docs/how-to-remediate-security-health-analytics-findings#kms_role_separation

[slevenick]

Changing to an enhancement as I believe this is a feature request for update support on google_pubsub_topic.kms_key_name

kmsKeyName looks like it is supported via the normal PATCH method here: https://cloud.google.com/pubsub/docs/reference/rest/v1/projects.topics/patch

[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!