5.2.1. Authorization Controls and Verified Permissions
First Principle: Different authorization needs require different mechanisms. IAM policies control AWS API access, resource policies control resource-level access, and Verified Permissions controls application-level access — each operating at a different layer.
IAM Authorization Layers:
| Layer | Policy Type | Who Sets It | What It Controls |
|---|---|---|---|
| Organization | SCPs, RCPs | Cloud platform team | Maximum permissions for all accounts |
| Identity | IAM policies | Account admins | What identities can do |
| Boundary | Permissions boundaries | Account admins | Maximum identity permissions |
| Resource | Resource policies (S3, KMS, SQS) | Resource owners | Who can access specific resources |
| Session | Session policies (via STS) | Calling identity | Scope of a specific session |
Amazon Verified Permissions (new in C03):
- Purpose-built for fine-grained application authorization
- Uses the Cedar policy language (open-source, developed by AWS)
- Evaluates authorization decisions within your application: "Can user X perform action Y on resource Z?"
- Externalizes authorization logic from application code — policies managed separately
- Integrates with Cognito for user identity and attributes
IAM Roles Anywhere (new in C03):
- Extends IAM role-based authorization to on-premises and hybrid workloads
- Uses X.509 certificates instead of long-term keys
- Session policies can further restrict what the assumed role can do
- Enables the same least-privilege model for non-AWS resources
Cross-Account Access Patterns:
- Resource policy: Granting access from Account A to Account B's S3 bucket
- IAM role trust policy: Account B trusts Account A to assume a role
- Organizations delegated administrator: Centralized service administration without management account
⚠️ Exam Trap: Verified Permissions is for application-level authorization (your app's users doing things in your app). IAM is for AWS API authorization (identities doing things with AWS services). Don't confuse the two.
Scenario: A SaaS application needs to authorize tenants to access only their own data. Rather than hardcoding authorization in application logic, you implement Verified Permissions with Cedar policies: permit(principal in Group::"tenant-123", action, resource in Folder::"tenant-123-data").
Reflection Question: How does externalizing authorization with Verified Permissions improve both security and maintainability compared to embedding authorization logic in application code?
