Cross-Region AssumeRole KMS Decrypt Auditor

Threat/Impact Level: HIGH | Exploitability/Downtime Risk: HIGH | Time to Fix: 15–30 mins

TL;DR

• What broke: An IAM role assumed cross-region is calling kms:Decrypt against a single-region KMS key in us-east-1. The key policy does not authorize the assumed-role principal, or the key is not replicated as a multi-region key, so KMS hard-rejects the call with AccessDenied.
• How to fix it: Either (a) replicate the KMS key as a multi-region key and reference the replica ARN in the target region, or (b) explicitly grant kms:Decrypt to the cross-region assumed-role principal in the us-east-1 key policy.
• Fast path: Use our Client-Side Sandbox above to auto-refactor this — paste your key policy and role trust policy and get a corrected diff without sending your ARNs to a third-party server.

An error occurred (AccessDenied) when calling the Decrypt operation:
User: arn:aws:sts::123456789012:assumed-role/cross-region-worker/session-id
is not authorized to perform: kms:Decrypt
on resource: arn:aws:kms:us-east-1:123456789012:key/mrk-abc123def456
because no resource-based policy allows the kms:Decrypt action

How to Fix It (The Solution)

Basic Fix — Add the Assumed-Role Principal to the KMS Key Policy

Navigate to the KMS key in us-east-1 → Key Policy → Edit. Add the cross-region role as an explicit principal.

 {
   "Version": "2012-10-17",
   "Statement": [
     {
       "Sid": "AllowDecryptForWorkloads",
       "Effect": "Allow",
       "Principal": {
         "AWS": [
-          "arn:aws:iam::123456789012:role/same-region-worker"
+          "arn:aws:iam::123456789012:role/same-region-worker",
+          "arn:aws:iam::123456789012:role/cross-region-worker"
         ]
       },
       "Action": [
         "kms:Decrypt",
         "kms:DescribeKey"
       ],
       "Resource": "*"
     }
   ]
 }

⚠️ This works but does not scale. Every new cross-region role requires a manual key policy edit.

Enterprise Best Practice — Multi-Region KMS Key with Condition-Locked Policy

The correct long-term fix is to promote the key to a multi-region key (or create a new MRK) and replicate it to the target region. The consuming workload references the replica key ARN in its own region, eliminating the cross-region KMS API call entirely. Lock the key policy with aws:PrincipalOrgID and aws:RequestedRegion conditions to prevent lateral abuse.

Step 1 — Enable multi-region replication (Terraform):

 resource "aws_kms_key" "app_key" {
   description             = "Application encryption key"
   deletion_window_in_days = 30
   enable_key_rotation     = true
-  multi_region            = false
+  multi_region            = true
 }

+resource "aws_kms_replica_key" "app_key_replica" {
+  description             = "Replica of app_key in eu-west-1"
+  primary_key_arn         = aws_kms_key.app_key.arn
+  provider                = aws.eu_west_1
+  deletion_window_in_days = 30
+}

Step 2 — Harden the key policy with org and region conditions:

 {
   "Sid": "AllowDecryptWithGuardrails",
   "Effect": "Allow",
   "Principal": {
     "AWS": "arn:aws:iam::123456789012:root"
   },
   "Action": [
     "kms:Decrypt",
     "kms:DescribeKey"
   ],
   "Resource": "*",
   "Condition": {
+    "StringEquals": {
+      "aws:PrincipalOrgID": "o-xxxxxxxxxx",
+      "aws:PrincipalTag/Environment": "production"
+    },
+    "StringLike": {
+      "aws:PrincipalArn": "arn:aws:iam::123456789012:role/cross-region-worker"
+    },
-    "Bool": {
-      "aws:SecureTransport": "true"
-    }
+    "Bool": {
+      "aws:SecureTransport": "true",
+      "aws:MultiFactorAuthPresent": "false"
+    }
   }
 }

Step 3 — Update the consuming workload to reference the replica ARN, not the primary:

 # In your application config or Terraform variable
-kms_key_arn = "arn:aws:kms:us-east-1:123456789012:key/mrk-abc123def456"
+kms_key_arn = "arn:aws:kms:eu-west-1:123456789012:key/mrk-abc123def456"

The workload now calls KMS in its own region against the replica. No cross-region KMS API traversal. Latency drops. The AccessDenied disappears.

💡 Tired of pasting proprietary infrastructure configs into public LLMs? Generic AI interfaces log your company's ARNs, connection strings, and private keys. StackEngine enforces client-side zero-trust boundaries—the sandbox above executes 100% locally in your browser. Drop your broken manifest above to redact secrets locally and synthesize deterministic patch drafts with your own API key.

(For CI/CD pipeline automation, install via npm i -g stackengine).

# .checkov.yml
checks:
  - CKV_AWS_7   # Ensure KMS key rotation is enabled
  - CKV2_AWS_64 # Ensure KMS key policy is not overly permissive
  - CKV_AWS_219 # Ensure KMS Multi-Region key is used where cross-region access is required

checkov -d ./terraform \
  --framework terraform \
  --check CKV_AWS_7,CKV2_AWS_64,CKV_AWS_219 \
  --hard-fail-on HIGH

# policy/kms_no_wildcard_principal.rego
package kms

deny[msg] {
  stmt := input.Statement[_]
  stmt.Effect == "Allow"
  stmt.Principal == "*"
  msg := sprintf(
    "KMS key policy statement '%v' grants access to wildcard principal — forbidden.",
    [stmt.Sid]
  )
}

deny[msg] {
  stmt := input.Statement[_]
  stmt.Effect == "Allow"
  stmt.Principal.AWS == "*"
  msg := sprintf(
    "KMS key policy statement '%v' grants AWS wildcard principal — forbidden.",
    [stmt.Sid]
  )
}

conftest test kms_key_policy.json --policy policy/

 resource "aws_kms_key" "app_key" {
   description  = "Application encryption key"
   multi_region = true
+
+  lifecycle {
+    prevent_destroy = true
+  }
+
+  tags = {
+    CrossRegionReplication = "enabled"
+    ManagedBy              = "terraform"
+    SecurityReviewed       = "true"
+  }
 }