KMS Key Policy Allows Global Access: Risks and Fixes

KMS keys sit at the heart of nearly everything sensitive you store in AWS: encrypted S3 objects, EBS volumes, RDS snapshots, Secrets Manager secrets, and more. The key policy is the primary access control for a KMS key, and unlike IAM policies, it is the one resource that does not defer to your account's IAM by default. If a key policy says "anyone can use me," then anyone with a path to that key can.

The account_kmspublic check looks at the resource policy attached to each customer-managed key (CMK) and raises a finding when the policy allows access from a wildcard principal. This post explains exactly what that means, why it is dangerous, and how to lock it down without breaking the services that rely on the key.

---

What this check detects

Every KMS key has a key policy, a JSON document that defines who can administer the key and who can use it for cryptographic operations. The check parses each key policy and flags any statement where:

• The Effect is Allow, and
• The Principal is set to "*" or {"AWS": "*"}, and
• There is no Condition block that meaningfully restricts who that wildcard resolves to (for example, a missing aws:PrincipalAccount or kms:CallerAccount condition).

A statement like this is exactly what triggers the finding:

{
  "Sid": "AllowEverything",
  "Effect": "Allow",
  "Principal": "*",
  "Action": "kms:*",
  "Resource": "*"
}

---

Why it matters

The danger comes from how KMS evaluates access. For a principal to use a key, access must be granted in both the key policy and the principal's IAM permissions, with one important exception: when the key policy grants access directly to a principal (or to *), the key policy alone can be sufficient for principals in the key's own account, and it opens a cross-account door for everyone else.

Here is the realistic attack path:

1. You leave a key policy with Principal: "*" and Action: kms:Decrypt.
2. An attacker compromises credentials for an IAM role in any AWS account, including their own attacker-controlled account.
3. If that role has a broad IAM policy like kms:Decrypt on Resource: "*", the cross-account call now succeeds, because your key policy explicitly allows it.
4. The attacker decrypts your data, or worse, calls kms:ScheduleKeyDeletion if the wildcard also covers administrative actions.

Beyond the direct breach, this is a compliance failure. PCI DSS, HIPAA, SOC 2, and CIS AWS Foundations all expect cryptographic keys to be restricted to least-privilege access. A globally accessible key policy is an easy audit finding and a hard one to explain away.

---

How to fix it

The fix is to replace the wildcard principal with the specific principals that genuinely need the key. Work through it in three steps: find out who is actually using the key, write a scoped policy, then apply it.

Step 1: Identify the offending key and current policy

List your customer-managed keys, then pull the current policy:

# List customer-managed keys
aws kms list-keys --query 'Keys[].KeyId' --output text

# View the key policy for a specific key
aws kms get-key-policy \
  --key-id 1234abcd-12ab-34cd-56ef-1234567890ab \
  --policy-name default \
  --output text

Step 2: Confirm who actually uses the key

Before tightening the policy, check CloudTrail so you do not break a live workload. KMS data events show every Decrypt, GenerateDataKey, and similar call along with the calling principal.

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=ResourceName,AttributeValue=1234abcd-12ab-34cd-56ef-1234567890ab \
  --max-results 50 \
  --query 'Events[].{Time:EventTime,User:Username,Event:EventName}' \
  --output table

Step 3: Write a scoped key policy

A sane baseline policy gives full administrative control to your account root (so IAM can manage the key) and grants usage only to the specific roles that need it. Replace the wildcard with something like this:

{
  "Version": "2012-10-17",
  "Id": "key-policy-scoped",
  "Statement": [
    {
      "Sid": "EnableIAMAdmin",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:root"
      },
      "Action": "kms:*",
      "Resource": "*"
    },
    {
      "Sid": "AllowKeyUsage",
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::111122223333:role/app-encryption-role",
          "arn:aws:iam::111122223333:role/backup-service-role"
        ]
      },
      "Action": [
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:GenerateDataKey",
        "kms:DescribeKey"
      ],
      "Resource": "*"
    }
  ]
}

If you need genuine cross-account access, do not use *. Name the external account explicitly and add a condition to be defensive:

{
  "Sid": "AllowSpecificExternalAccount",
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::444455556666:root"
  },
  "Action": [
    "kms:Decrypt",
    "kms:DescribeKey"
  ],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "kms:CallerAccount": "444455556666"
    }
  }
}

Step 4: Apply the new policy

aws kms put-key-policy \
  --key-id 1234abcd-12ab-34cd-56ef-1234567890ab \
  --policy-name default \
  --policy file://scoped-key-policy.json

Confirm the change took effect:

aws kms get-key-policy \
  --key-id 1234abcd-12ab-34cd-56ef-1234567890ab \
  --policy-name default \
  --output text | jq

---

How to prevent it from happening again

One-off fixes do not hold. Wildcard key policies usually creep back in through copied templates or "just make it work" debugging. Catch them before they ship.

Define keys in IaC with scoped policies

Manage keys in Terraform or CloudFormation so the policy is reviewable in a pull request. A Terraform example:

data "aws_caller_identity" "current" {}

resource "aws_kms_key" "app" {
  description             = "App data encryption key"
  deletion_window_in_days = 30
  enable_key_rotation     = true

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid       = "EnableIAMAdmin"
        Effect    = "Allow"
        Principal = { AWS = "arn:aws:iam::${data.aws_caller_identity.current.account_id}:root" }
        Action    = "kms:*"
        Resource  = "*"
      },
      {
        Sid       = "AllowAppUsage"
        Effect    = "Allow"
        Principal = { AWS = aws_iam_role.app.arn }
        Action    = ["kms:Encrypt", "kms:Decrypt", "kms:GenerateDataKey", "kms:DescribeKey"]
        Resource  = "*"
      }
    ]
  })
}

Gate it in CI/CD with policy-as-code

Add a check to your pipeline that rejects any KMS policy with a wildcard principal. With Checkov:

checkov -d . --check CKV_AWS_33

Or write a targeted OPA/Conftest rule that scans your plan output:

package kms

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "aws_kms_key"
  policy := json.unmarshal(resource.change.after.policy)
  statement := policy.Statement[_]
  statement.Effect == "Allow"
  statement.Principal == "*"
  msg := sprintf("KMS key %s allows a wildcard principal", [resource.address])
}

Use SCPs as a backstop

A Service Control Policy can deny the creation of overly permissive key policies across the whole org, so a single misconfigured account cannot expose a key. Pair this with a condition that prevents principals outside your organization from being added.

---

Best practices for KMS key policies

• Never use Principal: "*" in a key policy. If you think you need it, you almost certainly want a named role or the account root instead.
• Separate key administrators from key users. The team that can schedule deletion should not be the same as the service that encrypts data.
• Split usage actions from admin actions. Grant kms:Encrypt and kms:Decrypt to applications, and keep kms:ScheduleKeyDeletion, kms:PutKeyPolicy, and kms:DisableKey reserved for a small admin group.
• Prefer grants for temporary, fine-grained access rather than editing the key policy each time a workload needs short-lived access.
• Add condition keys for cross-account access. Use kms:CallerAccount, aws:PrincipalOrgID, or kms:ViaService to constrain who and how a key is used.
• Enable key rotation and CloudTrail data events. Rotation limits blast radius over time, and data events give you the audit trail you need to detect misuse.
• Use the kms:ViaService condition to ensure a key can only be used through an expected service, for example only via S3 in a specific region.

A KMS key policy is the last line of defense for your encrypted data. Treat a wildcard principal the same way you would treat a public S3 bucket holding production data: an incident waiting to be reported, not a convenience.

Scope every key to the principals that need it, enforce that rule in your pipeline, and let continuous scanning catch the ones that slip through. The fix takes minutes. The breach it prevents does not.