Support IAM policy bindings for KMS Keyring and CryptoKey resources

[tragiclifestories]

As things stand, the only way to manage cloudkms roles is at the project level, which is very coarse grained - especially given the actual function of cryptographic keys in a software system ;-)

Proposal is to have the same sort of interface as in similar resources (eg #481).

resource "google_kms_key_ring" "top_secret" {
  name     = "top-secret"
  location = "global"
  project  = "my-project-123"
}

data "google_iam_policy" "top_secret" {
  binding {
    role = "roles/cloudkms.encryptDecrypt"

    members = [
      "[email protected]",
      "[email protected]",
    ]
  }
}

resource "google_kms_key_ring_iam_binding" "top_secret" {
  key_ring = "${google_kms_key_ring.top_secret.id}"

  policy_data = "${data.google_iam_policy.top_secret.policy_data}"
}

[rosbo]

I agree that fine grained permissions is critical especially for cryptographic keys. Once #744 is merged. I will add IAM support for KMS resources.

[tragiclifestories]

@rosbo This still on your radar? I'm happy to take it (now that you've done all the hard work 😂 )

[rosbo]

@tragiclifestories I was planning to tackle this later this week but if you have time go for it and let me know if the new abstractions generalize well :)

[rosbo]

I found a bug while adding the IAM support for organization, make sure you have the change in #774 whenever you decide to tackle this.

[rosbo]

I added support for organization IAM here #775. You might want to use it as an example.

[rosbo]

This PR also refactor the authoritative resource #776 to allow easy reusability. You might want to use that for KMS resources.

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