Authorizing Users

IAM Policies

IAM Policies and Permissions

“A policy is an object that defines permissions for the identity or resource that it’s associated with.” Use policies to fine-tune the permissions granted to principals (IAM users, IAM roles, and AWS services).

Two Types of Policies

Identity-Based Policies

Attached to: IAM user, group, or role
Purpose: Indicate what the user is permitted to do
Question answered: What does a particular identity have access to?

Resource-Based Policies

Attached to: AWS resource
Purpose: Indicate what a specified user (or group of users) is permitted to do with the resource
Question answered: Who has access to a particular resource?

Most policies are stored in AWS as JSON documents. “AWS evaluates these policies when an IAM principal makes a request. Permissions in the policies determine whether the request is allowed or denied.”

Policy Evaluation Logic

When IAM determines whether an action is allowed, the service follows this evaluation logic:

Decision Flow

Default: All requests are denied by default
Explicit Allow: An explicit allow overrides the default deny
Explicit Deny: An explicit deny overrides any explicit allow

“A user will be permitted to take the action only if the requested action is not explicitly denied and is explicitly allowed.” When conflicts occur, “the most restrictive policy (that is, the policy that denies the action) is applied.”

Testing Policies

Use the IAM policy simulator to test and troubleshoot IAM policies - it’s a helpful tool to determine whether access to a resource will be granted to an IAM entity.

Policy Type Comparison Examples

Identity-Based vs Resource-Based Perspective

Identity-Based View
Resource-Based View

Carlos can:

Resource X: Read ✓, Write ✓, List ✓

Richard can:

Resource Y: Read ✓
Resource Z: Read ✓

Managers group can:

Resource X: List ✓
Resource Y: List ✓
Resource Z: List ✓

Policy Evaluation Examples

Example 1: Bob’s Access to Bucket X

Identity-based policy (attached to Bob):

Bucket X: GET ✓, PUT ✓, LIST ✓

Resource-based policy (attached to Bucket X):

Bob: GET ✓, PUT ✗, LIST ✓

Result: “Bob cannot PUT objects into bucket X, even though his identity-based policy allows it” because the resource-based policy explicitly denies PUT access.

Example 2: Bob’s Access to Bucket Y

Identity-based policy (attached to Bob):

Bucket Y: LIST ✓ (GET and PUT not specified)

Resource-based policy (attached to Bucket Y):

Bob: GET ✓, LIST ✓ (PUT not specified)

Result: “Bob can read objects from the bucket, even though his identity-based policy doesn’t explicitly allow it” because the resource-based policy provides the GET permission.

Cross-Account Access Example

Resource-based policies enable cross-account access. For example:

Account A creates a resource-based policy on an S3 bucket
Policy grants Account B (specified by account number) access to perform any S3 operation on the bucket
Account B should create an IAM user policy to allow specific users in Account B to access Account A’s bucket

Policy Interaction Principles

When multiple policies apply to a request:

Both types are evaluated: Identity-based and resource-based policies are both considered
Explicit deny wins: Any explicit deny in either policy type will override allows
Allow required: At least one policy must explicitly allow the action for it to be permitted
Default deny: If no explicit allow exists, the request is denied by default

Understanding policy types and their interactions is crucial for designing secure, well-controlled access to AWS resources while maintaining the principle of least privilege.

This section explained how IAM policies control authorization through identity-based and resource-based approaches, demonstrating the policy evaluation logic that determines whether requests are allowed or denied based on explicit allow and deny statements.