← Back to Labs L2 Intermediate

AWS · Security · Secret Access Authorization

AWS Secrets Manager Access Evaluation

Intermediate LAB for understanding how IAM permissions, secret resource policies, KMS decrypt authority, explicit deny, and organization guardrails combine into an effective secret-access decision.

Status Intermediate
Cloud AWS
Domain Security
Track L2 Applied

Overview

Secrets Manager access is a layered authorization decision. A principal may be allowed to request a secret, but still fail if the secret resource policy, KMS key policy, SCP, or explicit deny blocks the path.

L2 Intermediate Secret access KMS dependency No live mutation

Concept Deep Dives

Expand these concepts when studying secret retrieval or explaining sensitive credential access risk.

What is Secrets Manager access?

Secrets Manager access is the ability to list, describe, retrieve, or manage secrets. The most sensitive action is usually retrieving the secret value.

Why is GetSecretValue high risk?

GetSecretValue returns the sensitive material stored in the secret, such as database passwords, API tokens, service credentials, or application keys.

Why does KMS matter for secrets?

Secrets are encrypted. If a customer-managed KMS key protects the secret, the caller may need both Secrets Manager permission and KMS decrypt authority.

What is a secret resource policy?

A secret resource policy is a resource-based policy attached to a secret. It can define who may access the secret, including cross-account principals.

What should executives understand?

Secrets are high-value access material. The governance question is not only who can see secrets, but who can assume, pass, or chain into identities that can retrieve and decrypt them.

Visual Secrets Access Model

Secret access is easiest to understand as a layered retrieval decision.

Principal User, role, workload, service, or external account
IAM Policy Can request GetSecretValue?
Secret Resource Policy Does the secret trust the principal?
Secret Access Decision Retrieve, block, or deny
Secrets Manager Allows GetSecretValue is permitted
+
KMS Allows Decrypt is permitted
Secret Value Returned Unless explicit deny or guardrail blocks it
Secrets Manager Allows GetSecretValue is permitted
+
KMS Denies Decrypt is not permitted
Deny Secret value cannot be decrypted
Learning rule: secret access is not just "can I call Secrets Manager?" It is also "can this identity decrypt the protected secret value?"

Example Scenario

A workload role can request a secret, but the customer-managed KMS key does not allow that role to decrypt.

IAM policy: secretsmanager:GetSecretValue allowed
Secret resource policy: same-account access allowed
KMS key policy: workload role not trusted
Final decision: DENY

Authorization Layers

This lab connects secret access to the broader L2 authorization model.

Bridge to Principal LABs

Secrets are often the target after privilege escalation. A principal that can assume, pass, or chain into a role with Secrets Manager and KMS authority may retrieve sensitive credentials.

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 secrets
  • Does not retrieve secret values
  • Does not decrypt real data
  • Does not issue runtime tokens
  • Does not override OPA

Source Artifacts

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