Lesson 173 · AWS Learning Path

AWS 173: KMS key policies and envelope encryption

Anil Jalela · Published Dec 15, 2025 · 8 min read

Why this lesson matters

Evaluate key policy, IAM, grants, encryption context, data keys, and service delegation in the correct order.

What you will be able to do

By the end, you can:

• explain kms key policies and envelope encryption in plain language;
• locate the current service controls in the AWS Management Console;
• run the matching CloudShell or AWS CLI queries and explain every important field;
• draw the identity, network, data, failure, and monitoring path;
• choose the service from requirements and reject it when those requirements are absent;
• diagnose a failed or misleading result from evidence;
• state the cost owner and prove cleanup or a no-create result.

Before you start

• Use a personal AWS account only when its owner has approved the lesson. Do not use the root user for daily work.
• CloudShell is the default command environment. AWS028 explains CloudShell; AWS029 and AWS030 explain local AWS CLI installation and profiles.
• The course example Region is ap-south-1. Global services and services with a required control Region are called out in their commands.
• Run aws sts get-caller-identity privately. Redact the account number before sharing evidence.
• Never paste access keys, passwords, secret values, private object data, presigned URLs, or full account-specific ARNs into a submission.
• This is a no-create lesson. Every Console action and AWS CLI command is read-only. Create the practical artifact locally.
• Console wording can change. Use the Console service search if a menu label has moved, then confirm the current field in the official documentation.

The core model

How the request flows

+------------------------------------+
|  Principal and encryption context  |
+------------------------------------+
                  |
                  v
+-----------------------------------------+
|  Key policy, IAM, and grant evaluation  |
+-----------------------------------------+
                    |
                    v
+--------------------------------+
|  Generate or decrypt data key  |
+--------------------------------+
                |
                v
+-----------------------------------------+
|  Local data encryption and audit event  |
+-----------------------------------------+

Read a KMS authorization decision correctly

KMS authorization is resource-policy centered. A customer managed key always has a key policy. The default programmatic policy commonly enables the account principal to use IAM policies, but that statement is delegation authority, not a grant to every identity. A console-created policy may also add key administrators and key users. Administrators who can change policy can often give themselves cryptographic access, so separation of duties must consider escalation paths rather than statement labels.

Evaluate a request in this order:

1. Identify the exact caller session with sts get-caller-identity, including assumed-role session context.
2. Identify the exact key ARN, account and Region; aliases are regional pointers.
3. Check key state, usage and cryptographic algorithm before policy debugging.
4. Evaluate explicit denies from key policy, SCP, resource control policy, IAM, permission boundary, session policy and VPC endpoint policy.
5. Find an applicable allow in the key policy, an IAM policy enabled by the key policy, or a grant.
6. Verify conditions: encryption context, kms:ViaService, source account/resource, grant operations and grant constraints.

Cross-account access requires two sides: the key policy in account A must trust the external principal/account, and identity permissions in account B must allow the KMS operation on that key. An alias from account B cannot identify account A's key for cryptographic operations; use the key ARN.

Policy roles that must not be confused

Avoid Principal: "*" unless restrictive conditions make the intended boundary demonstrable. Never use a key policy condition as a substitute for reviewing who can modify that policy.

Envelope encryption in implementation detail

KMS direct Encrypt is intended for small payloads and has API size limits; use a data key or an AWS Encryption SDK for application data. GenerateDataKey returns both plaintext and encrypted forms. Store only the encrypted form with the ciphertext. Encryption context is authenticated additional data: it is logged in CloudTrail and therefore must not contain secrets. Context keys and values must match at decrypt.

Data-key caching can reduce KMS calls and latency, but it increases the amount of data and time protected by one plaintext key. Set limits for age, bytes and messages; isolate caches by tenant and encryption context. For client-side encryption, store algorithm suite, encrypted data key, context and framing/version metadata so future readers can decrypt safely.

Grants are useful for temporary or service-mediated delegation. A grant specifies grantee, operations and optional encryption-context constraints. Creation is eventually consistent; a grant token can bridge that delay. Retire or revoke grants when the integrating resource is removed, and inspect grants before assuming a policy edit removed access.

Rotation and migration decision

Automatic/on-demand material rotation preserves the key ID and decryptability of old ciphertext; aliases and policies do not change, and existing data is not rewritten. Create a new key and repoint an alias when you need a new policy boundary, account, Region, origin, key spec or usage. Migration then requires testing reads with old ciphertext, writing new ciphertext under the new key, retaining old decrypt capability for the data-retention period, and proving rollback.

Architecture decision table

AWS Management Console, step by step

Sign in with the normal non-root learning identity. Write the expected starting state before opening the service.

1. Use the Console service search and open KMS, Customer managed key, Key policy and CloudTrail event evidence; confirm the account and Region before reading the page.
2. Inspect the supplied or owned resource's status, configuration, permissions, networking, encryption, monitoring, tags, and dependencies without changing it.
3. Open the related metrics, logs, events, or history view and record one timestamped signal that would prove or disprove the expected behavior.
4. Return to the resource list, clear filters, and record the final inventory. On the read-only track, do not choose Create, Save, or Delete.

CloudShell and AWS CLI, step by step

Start with a known caller and Region:

export AWS_DEFAULT_REGION="ap-south-1"
aws sts get-caller-identity --query Arn --output text
aws configure list

Redact the account part of the ARN in shared evidence. Now run the topic queries:

aws kms get-key-policy --key-id replace-with-key-id --policy-name default --output text
aws kms list-grants --key-id replace-with-key-id --output table
aws kms get-key-rotation-status --key-id replace-with-key-id --output json

Expected interpretation

Policy text is only one authorization layer. Envelope encryption returns an encrypted data key; the plaintext data key must be protected in memory and never stored with plaintext data.

Practical work

Trace an S3 service encrypt request and an application envelope-encryption request. Identify caller, key-policy statement, IAM permission, encryption context, data key, ciphertext, decrypt path, and CloudTrail evidence.

Diagnose this topic from its own evidence

• If IAM shows Allow but KMS denies, inspect whether the key policy enabled IAM delegation and whether a key-policy or organization-level deny applies.
• If only an AWS service fails, compare direct-call permission with the service principal, grant and kms:ViaService condition.
• If decrypt fails after application deployment, compare ciphertext key ARN, Region and exact encryption context before changing permissions.
• If a new grant appears ineffective, pass its grant token for the immediate operation or wait for consistency; do not duplicate broad grants.
• Use CloudTrail Decrypt, GenerateDataKey, CreateGrant, PutKeyPolicy, DisableKey and ScheduleKeyDeletion events to reconstruct actor, parameters and outcome without exposing plaintext.

Cost and cleanup

Requests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design.

Knowledge check

1. What operational purpose is this lesson solving?

Expected direction: Evaluate key policy, IAM, grants, encryption context, data keys, and service delegation in the correct order.

1. Which scope or ownership boundary must be proved first?

Expected direction: The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for KMS policies and envelope encryption.

1. What evidence is strong enough to accept the result?

Expected direction: Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for KMS policies and envelope encryption.

1. Which tempting design or shortcut must be rejected?

Expected direction: Avoid storing plaintext data keys, granting kms:*, or omitting encryption-context conditions where they reduce misuse.

1. Which cost dimensions and retained resources need an owner?

Expected direction: Requests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design.

Lesson acceptance

• Annotate a key policy showing administration, usage, IAM delegation and explicit-deny effects.
• Prove the two-account authorization path for a cross-account decrypt design.
• Explain envelope encryption, encryption-context confidentiality limits and data-key cache trade-offs.
• Compare rotation-in-place with new-key migration and include rollback/read-old-data handling.
• Diagnose one supplied deny from caller, policy layers, conditions, grants, key state and CloudTrail evidence.

Official sources

• KMS key policies
• How KMS evaluates authorization
• Grants in KMS
• Encryption context
• Envelope encryption
• AWS security documentation
• Security Pillar