Cloud KMS keys should not be open to anonymous or public access

A Cloud KMS key protects other data: disks, buckets and databases encrypted with it depend on who may use it. If a key grants a role to allUsers (anyone on the internet) or allAuthenticatedUsers (anyone with a Google account), the people who can use or manage the key are no longer limited to your own staff and service accounts.

Google's documentation says roles can be granted on a key, key ring, project, folder or organization, that lower levels inherit grants from higher ones, and that you should use the least-privilege role for each job. A public principal in any of those places is the opposite of that approach.

Source: Identity and Access Management for Cloud KMS, Google Cloud documentation.

In the Google Cloud console open Security, then Key Management, select a key ring and a key, and open the Permissions tab. Look for the principals allUsers and allAuthenticatedUsers. Because grants inherit, also check the key ring and the project.

From the command line, these read-only commands list the keys and print the policy of each:

gcloud kms keyrings list --location <location>
gcloud kms keys list --keyring <key-ring> --location <location>
gcloud kms keys get-iam-policy <key> \
  --keyring <key-ring> --location <location> --format=json

Any binding whose members list contains allUsers or allAuthenticatedUsers is a finding.

In the console, on the key's Permissions tab, remove the public principal from each role. From the command line (review it, then run it yourself; ConfigCobra never changes your tenant):

gcloud kms keys remove-iam-policy-binding <key> \
  --keyring <key-ring> --location <location> \
  --member allUsers \
  --role roles/<role-name>

Repeat with allAuthenticatedUsers if present. Per Google's documentation, only principals with the Owner or Cloud KMS Admin role can grant or revoke access. If a public binding comes from a key ring or project, remove it at that level instead.

Anyone who used the key through the public grant loses access. For a key that really was meant to be public, such as one shared with an outside party, expect that party's calls to fail; give them a named account or group with the narrowest role instead.

Internal workloads that use the key through their own service accounts are not affected. Before removing a binding, search audit logs or ask the key owner who uses it, so a legitimate integration is not cut off by surprise.