AWS KMS: Cross-Account Encryption & Key Management

Cross-account encryption allows AWS resources in one account (the Consumer) to use a Customer Managed Key (CMK) located in another account (the Producer). This is a critical skill for the DVA-C02 exam, particularly for multi-account architectures and centralized security logging.

Learning Objectives

After studying this guide, you should be able to:

Configure a KMS Key Policy to grant access to external AWS accounts.
Identify the necessary IAM permissions required for a principal in a different account.
Differentiate between Resource-based policies and Identity-based policies in the context of cross-account access.
Describe the flow of encrypting/decrypting data across account boundaries (e.g., S3 cross-account uploads).

Key Terms & Glossary

Key Policy: A resource-based policy attached to a KMS key that defines who can use or manage it. This is the primary way to control access to a key.
Grant: A mechanism that allows an AWS principal to use a KMS key in cryptographic operations, often used for temporary or programmatic permissions.
External Account Principal: In a policy, this is typically represented as "AWS": "arn:aws:iam::111122223333:root" to delegate permission to Account 111122223333.
CMK (Customer Managed Key): A KMS key that you create and manage. Unlike AWS Managed Keys, CMKs allow cross-account access.

The "Big Idea"

In AWS, security boundaries are strictly enforced by account IDs. To "pierce" this boundary for encryption, you need a handshake. Account A (the key owner) must open the door via a Key Policy, and Account B (the key user) must permit its users to walk through that door via an IAM Policy. Without both permissions, the cross-account request will fail (Implicit Deny).

Formula / Concept Box

Requirement	Location	Purpose
Key Policy	Account A (Key Owner)	Must specify Account B's root (or specific IAM ARN) as a allowed principal.
IAM Policy	Account B (Key User)	Must grant the specific User/Role permission to `kms:Decrypt`, `kms:Encrypt`, or `kms:GenerateDataKey`.
CMK Type	Account A	Must be a Customer Managed Key. AWS Managed Keys cannot be shared across accounts.

Hierarchical Outline

I. Prerequisites for Cross-Account KMS
- Only Customer Managed Keys (CMKs) support cross-account access.
- AWS Managed Keys (e.g., aws/s3) are restricted to the local account.
II. Step 1: Configuring Account A (Producer)
- Modify the Key Policy.
- Add Account B's ARN to the Principal section.
- Grant specific actions (e.g., kms:Decrypt, kms:DescribeKey).
III. Step 2: Configuring Account B (Consumer)
- Attach an IAM Policy to the User or Role.
- The Resource field in the IAM policy must be the full Key ARN from Account A.
IV. Common Use Cases
- S3 Cross-Account: Account B uploads to a bucket in Account A using Account A's KMS key.
- EBS Snapshots: Sharing encrypted snapshots across accounts.

Visual Anchors

Cross-Account Permission Flow

Loading Diagram...

The Relationship Diagram

\begin{tikzpicture}[scale=0.8, every node/.style={transform shape}] \draw[thick, fill=blue!10] (0,0) rectangle (4,4) node[pos=.5, yshift=1.5cm] {Account A}; \draw[thick, fill=green!10] (6,0) rectangle (10,4) node[pos=.5, yshift=1.5cm] {Account B}; \node[draw, cylinder, alias=key, shape border rotate=90, aspect=1.5, fill=yellow!30] at (2,2) {KMS Key}; \node[draw, circle, fill=orange!30] at (8,2) {IAM Role}; \draw[->, ultra thick, red] (7.2,2) -- (2.8,2) node[midway, above] {KMS API Call}; \node[text width=3cm, align=center] at (2,-1) {\small Resource Policy$Key Policy)}; \node[text width=3cm, align=center] at (8,-1) {\small Identity Policy$IAM Policy)}; \end{tikzpicture}

Definition-Example Pairs

Term: kms:GenerateDataKey
Definition: An API operation that returns a unique plaintext data key and a copy of that key encrypted under the specified KMS key.
Example: When Account B wants to upload a file to an S3 bucket in Account A using Account A's KMS key, the S3 service (acting for Account B) calls GenerateDataKey to get a key for the specific object.
Term: Envelope Encryption
Definition: The practice of encrypting data with a data key, and then encrypting the data key under another key (the KMS key).
Example: Instead of sending 5GB of raw data to KMS (which has a 4KB limit for the Encrypt API), you use a data key to encrypt the 5GB file locally and only use KMS to protect that tiny data key.

Worked Examples

Scenario: Cross-Account S3 Upload

Goal: An IAM User in Account B (111111111111) needs to upload a file to a bucket in Account A (222222222222) and encrypt it using a CMK in Account A.

Step 1: Key Policy in Account A Modify the CMK policy to include:

json

{
  "Sid": "Enable Cross Account Access",
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::111111111111:root"
  },
  "Action": [
    "kms:Encrypt",
    "kms:GenerateDataKey*",
    "kms:DescribeKey"
  ],
  "Resource": "*"
}

Step 2: IAM Policy in Account B Attach this to the user in Account B:

json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "kms:Encrypt",
        "kms:GenerateDataKey*"
      ],
      "Resource": "arn:aws:kms:us-east-1:222222222222:key/your-key-id"
    }
  ]
}

Checkpoint Questions

Can you use the default AWS Managed Key for S3 (aws/s3) to encrypt data from a different account?
- Answer: No. Only Customer Managed Keys (CMKs) support cross-account access via policy modification.
If the Key Policy allows Account B, but Account B's IAM policy does not mention the key, will the operation succeed?
- Answer: No. Cross-account access requires an explicit "Allow" in both the Key Policy and the IAM Policy.
What is the maximum size of data that can be sent directly to the kms:Encrypt API?
- Answer: 4 KB. For larger data, you must use envelope encryption (GenerateDataKey).
Why do we use "AWS": "arn:aws:iam::111122223333:root" in a Key Policy instead of listing every user?
- Answer: Specifying the root account delegates the power to the administrators of that account to further distribute permissions using IAM policies.