Description
Including broad principals such as allUsers or allAuthenticatedUsers in a GCP KMS Crypto Key IAM policy can grant key permissions beyond the intended audience. The impact depends on the role; decryption permission together with access to the relevant ciphertext can compromise data confidentiality.
IAM access to a key does not mean that its key material is published. The example role, roles/cloudkms.cryptoKeyEncrypter, permits encryption and does not itself grant decryption. Service authentication requirements and applicable policies also affect requests.
Potential impact
- Unintended principals may perform the key operations granted to them.
- Excessive decryption or administrative permissions can affect sensitive data or services that depend on the key.
Remediation
Remove unnecessary grants to allUsers and allAuthenticatedUsers, and identify only the approved principals that use the key. Separate encryption, decryption and administration roles as needed, limiting grants to individual keys where possible. Preserve required service-account access when updating policies, then verify that legitimate operations succeed and unapproved requests are denied.
Examples
These excerpts generate an IAM policy document. The configuration that applies it to a KMS key is omitted. Replace the sample user address with an actual approved principal.
Before
data "google_iam_policy" "kms_policy" {
binding {
role = "roles/cloudkms.cryptoKeyEncrypter"
members = ["allUsers"]
}
}
This policy document grants the encryption role to allUsers. Avoid including such a broad principal in a key policy.
After
data "google_iam_policy" "kms_policy" {
binding {
role = "roles/cloudkms.cryptoKeyEncrypter"
members = [
"user:jane@example.com"
]
}
}
This restricts the encryption role to a named user. Review permissions from other roles and inherited policies too.