-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Please add "name" as an attribute to the data source: kms_crypto_key_version #9729
Please add "name" as an attribute to the data source: kms_crypto_key_version #9729
Comments
Linked bug : https://b.corp.google.com/issues/195644022 |
I have submitted a patch. In the interim, the following should work: // Create key at the same time or reference with the above datasource and append /1 to it.
key_spec {
cloud_kms_key_version = "${google_kms_crypto_key.key}/cryptoKeyVersions/1"
} @rileykarson Patching the datasource won't actually be that helpful. There will still be a point in time where the cryptoKeyVersion is unknown in terraform especially if the Cryptokey and the CA are being created simultaneously which is rather common. The example of the OP requires two applies for it work properly. Unless you do the string interpolation hack at the top of my comment AND you didn't set skipInitialVersionCreation to true. Right now, we are shortening the Is it worth repurposing self_link field to actually return the full value? and rework #8275?
|
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. |
Hi, it would be great if we could get the key of "Name" for kms_crypto_key_version - The API supports it, but the terraform does not. this would provide a full name (rather than ID) such as projects//locations//keyRings//cryptoKeys//cryptoKeyVersions/*.
which in turn, is needed for the new GCP CAS (formally PrivateCA) when it asks for a KMS key version in the above expected path when using a CMEK.
Cant figure out another way to get this information dynamically..
This is currently affecting a customers ability to roll out CAS.
Potential Terraform Configuration
In the example above, key_spec expects to be pointed to a key version path, and by having name available, it presents the correct syntax needed by the CA service to successfully build. Current work around is to manually set this as a variable, after the key has been built the first run through..
References
API: https://cloud.google.com/kms/docs/reference/rest/v1/projects.locations.keyRings.cryptoKeys.cryptoKeyVersions
Terraform: https://registry.terraform.io/providers/hashicorp/google/latest/docs/data-sources/kms_crypto_key_version)
The text was updated successfully, but these errors were encountered: