← Back to Labs L2 Intermediate

AWS · Identity · Resource-Side Authorization

AWS Resource Policy Evaluation

Intermediate LAB for understanding how AWS resource-based policies participate in authorization decisions alongside identity policies, permission boundaries, SCPs, and explicit deny.

Status Intermediate
Cloud AWS
Domain Identity
Track L2

Overview

Resource policies define who can access a resource and under what conditions. They are essential for cross-account access, resource-side explicit deny, and trust-policy reasoning.

L2 Intermediate Resource-side authorization Cross-account reasoning No live mutation

Concept Deep Dives

Expand these concepts when studying resource-side authorization or explaining cross-account access.

What is a resource policy?

A resource policy is a policy attached to a resource. It defines which principals may access that resource and which conditions must be true for access to succeed.

How is a resource policy different from an identity policy?

An identity policy is attached to a principal and says what the principal may request. A resource policy is attached to a resource and says who the resource trusts or denies.

Why do resource policies matter for cross-account access?

Cross-account access often requires the resource to explicitly trust an external principal. Without the resource-side trust, the external principal may be blocked even if its own account allows the request.

What is a role trust policy?

A role trust policy is a resource-based policy attached to an IAM role. It controls which principals are allowed to assume the role.

What should executives understand?

Resource policies can expose sensitive assets or trust external identities. They must be reviewed as part of enterprise identity governance, not only as application configuration.

Visual Resource Policy Model

Resource policy reasoning is easiest when viewed as a two-sided authorization decision.

Principal User, role, workload, service, or external account identity
→
Identity Policy Principal-side requested authority
→
Resource Policy Resource-side trust or deny decision
→
Effective Decision Final allow or deny after all policy layers
Identity Allows The principal may request the action
+
Resource Allows The resource trusts the principal
→
Possible Allow Unless boundary, SCP, or explicit deny blocks it
Identity Allows The principal may request the action
+
Resource Denies The resource policy blocks the request
→
Deny Resource-side deny overrides the apparent allow
Learning rule: resource policies are the resource side of authorization. For cross-account access, both sides matter.

Example Scenario

A role has an identity policy allowing S3 object access, but the bucket policy denies access unless the request comes through an approved VPC endpoint. 

Identity policy: s3:GetObject allowed
Resource policy: deny unless aws:sourceVpce matches approved endpoint
Final decision: DENY when the request violates the resource policy condition

Bridge to Principal LABs

Resource policy evaluation prepares learners for advanced identity paths because cross-account trust depends on resource-side authorization.

Cross-Account Role Escalation Role trust policies are resource policies that control who can assume a role. iam:PassRole Privilege Escalation Resource-side trust and service role design influence escalation paths. Role Chaining Escalation Each role assumption depends on a trust relationship that must be evaluated.

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 issue runtime tokens
  • Does not override OPA

Source Artifacts

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