Cloud policy decisions: trace every authorization layer

Last updated: 5 Oct 20266 min read

tutorial

A cloud API request is evaluated against the caller identity, action, resource, request context, and several policy layers. An identity allow can be narrowed by a permissions boundary, session policy, or organization guardrail; an applicable explicit deny wins. Resource policies and cross-account requests add further rules, including cases where a grant to a role session behaves differently from a grant to the role ARN. A policy simulator is useful, but a controlled real request remains the acceptance test for a service integration.

Operational decision

A deployment role can upload a receipt bundle but cannot update the key policy protecting that bundle. When a deployment receives AccessDenied, first capture the exact API action, resource ARN, account, region, caller ARN, assumed-role session ARN, and condition values. Read the identity policy, boundary, session policy, organization controls, resource policy, and encryption-key policy as a single decision record. Check the service's authorization reference for resource scoping and condition support; an action that does not support the intended resource type can make a precise-looking allow ineffective. Test one approved operation and one deliberately denied operation in a disposable account. If the request is cross-account, verify permissions on both sides and the relevant service-specific resource rules. Record the matched statement and the policy version used at the time of the test. Do not fix an obscure denial by attaching administrator access to the role: that obscures the actual failed condition and expands unrelated permissions. An error message may identify one denial reason without proving every other layer would allow the request after that reason is removed.

Receipt deploy authorization worksheet
Caller: account, role ARN, session ARN, source identity
Request: API action, resource ARN, region, condition context
Ceilings: boundary, session policy, organization controls
Resource side: bucket and key policies where applicable
Proof: approved request succeeds; prohibited request is denied
Evidence: policy versions and request identifiers retained

Cost and verification

Evaluating P policy statements conceptually requires checking the statements relevant to one action and resource; diagnostic effort grows with P and with the number of policy layers. Wildcards may reduce policy size but increase the blast radius of a mistake. Measure authorization failures by action and role, time to identify the denying layer, and unexpected successes found by negative tests. Keep audit identifiers, not credentials or signed requests, in the incident record.

Common Mistakes

Do not treat an identity allow as final authorization.
Do not assume a simulator reproduces every service-side condition.
Do not widen the role before checking the exact resource and request context.

Connected lessons

Practice and check

devops

cloud-security