2.1.1.7. Resource Policies vs. IAM Policies (Tricky Distinction)

💡 First Principle: IAM policies define who (an identity) can access resources, while resource policies define what resources can be accessed and by whom, often from other accounts or services. Both are crucial for precise access control.

The fundamental distinction: IAM policies define who (an identity) can access resources, while resource policies define what resources can be accessed and by whom, often from other accounts or services. Both are crucial for precise access control.

• IAM Policies (Identity-Based): Attached to an IAM identity (user, group, role), they specify what actions that identity can perform on resources. They grant permissions to a principal.

• Resource Policies (Resource-Based): Embedded directly within a resource (e.g., S3 bucket, SQS queue), they specify who can access that specific resource and what actions they can perform. Essential for cross-account access.

Key Differences:

• "IAM Policies": Attached to identity, grant permissions to an identity.
• "Resource Policies": Attached to resource, define access on the resource.
• Evaluation: Both must allow an action for it to be permitted.

Scenario: An S3 bucket policy grants read access to an external account, while an IAM user policy in your account grants a user permission to put objects into that S3 bucket.

Visual: IAM Policies vs. Resource Policies

Loading diagram...

⚠️ Common Pitfall: Forgetting that for an action to be permitted, both the identity's IAM policy and the resource's resource policy (if it exists) must allow it. If one denies, access is denied.

Key Trade-Offs:

• Centralized Control (IAM Policies) vs. Distributed Control (Resource Policies): IAM policies are managed centrally in IAM. Resource policies are managed at the resource level, which can provide more direct control for that specific resource but might be harder to audit holistically.

Reflection Question: How could misconfigurations involving both IAM policies and resource policies lead to unintended access or denial in cross-account scenarios, highlighting the importance of understanding their interplay?