Terraform-provider-google: Add feature to delete key material and disable key rotation on destroy of a TF stack

Created on 11 May 2019  ·  5Comments  ·  Source: hashicorp/terraform-provider-google

The KMS service does not allow deletion of keyrings and keys, instead, rotation has to be removed and key material scheduled for destruction.

Terraform has left me with 40 keyrings and keys (from testing and laboratories) which I had to manually get rid of (disable rotation and destroy key material).

Why is this not part of the kms component?

Most helpful comment

ah, you're right, this is a bug - we need to null out the rotation period/next rotation when we "destroy". I'll put out a fix.

All 5 comments

I'm not sure what you mean by "disable rotation" but in general we, on key destroy, go through and delete all CryptoKeyVersions (see code), which schedules the key material for destruction.

I just tried this with the example config and it seems to be working as intended, i.e. the key versions are moved to state DESTROY_SCHEDULED and then automatically marked as DESTROYED after 24 hours. From the API docs:

Destruction is removal of the key material, but a record of the version still exists (e.g., the version number cannot be reused).

Hi @emilymye, thanks for your quick reply.

I just did a quick test.
The key material is scheduled for destruction, however the rotation schedule is not removed, apparently this is a separate step also.
key_after_destroy
This causes that new key material is provisioned automatically by the service on next rotation.

As you can see in the picture attached from my test, after a 'tf destroy' the key is effectively destroyed, but rotation 'In 1 day'.

I got to this issue as I had a $30 charge in my gcp account which I did not know where it was coming from, as I had no resources. When checking, I found 40 KMS keyrings, with 1 key each, which should have been deleted, yet two months later still there.
I had to script the deletion of the key material (quite a few, around 1k) and the removal of the rotation schedule.

Here is the tf script I used (tested with provider 2.1.0 and 2.6.0):

variable "google_credentials" {
  type = "string"
}

variable "google_project" {
  type = "string"
}

locals {
  google_default_region = "us-east1"
}

provider "google-beta" {
  credentials = "${var.google_credentials}"
  region      = "${local.google_default_region}"
  project     = "${var.google_project}"
}

provider "google" {
  credentials = "${var.google_credentials}"
  region      = "${local.google_default_region}"
  project     = "${var.google_project}"
}

resource random_id vault_key_name_suffix {
  byte_length = 8
}

resource google_kms_key_ring vault_poc {
  name     = "vault-poc-${random_id.vault_key_name_suffix.hex}"
  location = "global"
}

# vault key
resource google_kms_crypto_key vault_poc {
  name            = "vault-poc-${random_id.vault_key_name_suffix.hex}"
  key_ring        = "${google_kms_key_ring.vault_poc.self_link}"
  rotation_period = "100000s"
}

ah, you're right, this is a bug - we need to null out the rotation period/next rotation when we "destroy". I'll put out a fix.

Awesome, thanks for keeping on top of this Emily!

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 👉 [email protected]. Thanks!

Was this page helpful?
0 / 5 - 0 ratings