← Back to Labs L2 Intermediate

AWS · Security · Cryptographic Authorization

AWS KMS Key Policy Evaluation

Intermediate LAB for understanding how KMS key policies, IAM permissions, grants, encryption context, and guardrails combine into an effective cryptographic access decision.

Status Intermediate
Cloud AWS
Domain Security
Track L2 Applied

Overview

KMS key policies control cryptographic access. A principal can have access to a service resource but still fail to decrypt data when the KMS key policy, grant, or encryption context does not permit the operation.

L2 Intermediate Cryptographic authorization Key policy reasoning No live mutation

Concept Deep Dives

Expand these concepts when studying KMS key policies or explaining data-protection access decisions.

What is a KMS key policy?

A KMS key policy is the resource policy attached to a KMS key. It defines who can administer the key and who can use the key for cryptographic operations such as encrypt, decrypt, and generate data keys.

Why is KMS different from ordinary resource policies?

KMS protects cryptographic access to data. A user may reach an encrypted object or secret, but still fail if KMS does not allow the decrypt operation.

What is a KMS grant?

A KMS grant delegates permission to use a key, often for AWS services or workloads. Grants can allow specific cryptographic operations under defined conditions.

What is encryption context?

Encryption context is additional authenticated metadata passed with KMS operations. Policies and grants can require matching context values before decrypt is allowed.

What should executives understand?

KMS is a data-protection control plane. Weak key policies can expose encrypted data, while overly restrictive policies can break business-critical services.

Visual KMS Authorization Model

KMS access is easiest to understand as a cryptographic decision path.

Principal User, role, workload, AWS service, or external account
→
IAM Policy Principal-side request authority
→
KMS Key Policy Key-side trust and usage authority
→
KMS Decision Encrypt, decrypt, generate data key, or deny
IAM Allows The principal may request kms:Decrypt
+
Key Policy Allows The key trusts the principal or account path
→
Possible Allow Unless grant, context, SCP, or deny blocks it
IAM Allows The principal has an apparent allow
+
Key Policy Does Not Trust The key does not permit the path
→
Deny Cryptographic access fails
Grant Allows A grant delegates key usage
+
Encryption Context Request metadata must match policy expectations
→
Context-Aware Decision Allow or deny based on context match
Learning rule: KMS authorization is not only "can I access the resource?" It is also "can this principal use this key for this cryptographic operation in this context?"

Example Scenario

A workload role has an IAM policy allowing kms:Decrypt, but the KMS key policy does not trust that role. 

IAM policy: kms:Decrypt allowed
KMS key policy: workload role not trusted
Grant: none
Encryption context: not applicable
Final decision: DENY

Authorization Layers

This lab connects cryptographic access control to the broader L2 authorization model.

IAM Policy Evaluation Can the principal request KMS operations? Resource Policy Evaluation How does the key policy participate as resource-side authorization? SCP Guardrail Reasoning Can the organization prevent risky KMS administration or usage? S3 Public Access Risk Does encryption reduce exposure, or does key policy design permit decrypt?

Bridge to Principal LABs

KMS access often becomes valuable after identity escalation. A principal that can assume, pass, or chain into a role with KMS authority may gain access to encrypted data.

iam:PassRole Privilege Escalation Passed roles may inherit decrypt authority through key policy or grants. Cross-Account Role Escalation Cross-account KMS access requires careful key policy and principal trust review. Role Chaining Escalation Chained roles may eventually reach cryptographic authority.

Governance Boundary

This lab is read-only and deterministic. 

Runtime = source of truth
OPA = decision authority
Aegis = bounded intelligence
Frontend = rendering only
  • Does not exploit AWS
  • Does not mutate infrastructure
  • Does not deploy live resources
  • Does not enumerate real keys
  • Does not decrypt real data
  • Does not issue runtime tokens
  • Does not override OPA

Source Artifacts

  • metadata.json
  • architecture.md
  • index.html