Decoding IAM: Roles, Policies, and Trust Relationships for AWS Success

4 min readJan 21, 2025

AWS Identity and Access Management (IAM) is a cornerstone of AWS security, providing granular control over access to AWS resources. This guide dives deep into IAM roles, policies, and trust relationships, offering a structured understanding to simplify these critical concepts.

1. Introduction to IAM

IAM enables secure access control across AWS services. It helps define who (identity) can do what (permissions) and under what conditions.

Key Concepts:

Principal: An entity (user, role, service) that makes a request.
Authentication: Verifying the identity of a principal.
Authorization: Granting or denying permissions based on policies.

2. IAM Policies

Policies are JSON documents that define permissions. They dictate what actions a principal can perform on specific resources.

Types of Policies:

1. Identity-Based Policies

These policies are attached to IAM users, groups, or roles. They grant permissions for specific actions and resources. They are the most common type of policy in AWS.

Example Policy Template:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::example-bucket/*"
    }
  ]
}

2. Resource-Based Policies

These policies are attached directly to resources like S3 buckets, KMS keys, or Lambda functions. They define who can access the resource and under what conditions.

Example for S3 Bucket Policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/ExampleRole"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::example-bucket/*"
    }
  ]
}

3. SCP (Service Control Policies)

Service Control Policies are used in AWS Organizations to manage permissions at the account level. SCPs act as permission filters, defining what actions are allowed or denied. They do not grant permissions directly but restrict them.

Example SCP Template:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "ec2:TerminateInstances",
      "Resource": "*"
    }
  ]
}

4. Permissions Boundaries

Permissions boundaries are policies that define the maximum permissions an identity-based policy can grant. They are typically used to enforce least privilege access across an organization.

Example Permissions Boundary Template:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*"
    }
  ]
}

5. Inline Policies

Inline policies are embedded directly into a single IAM user, group, or role. They are specific to the entity they are attached to and are not reusable.

Example Inline Policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "dynamodb:GetItem",
      "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/ExampleTable"
    }
  ]
}

6. Session Policies

Session policies are temporary, inline policies associated with STS session tokens. They restrict permissions further during a session.

Example Session Policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::example-bucket/*"
    }
  ]
}

3. IAM Roles

IAM roles are identities with permissions policies attached. Unlike users, roles are assumed by trusted entities like applications, services, or users in other AWS accounts.

Key Characteristics:

Temporary Credentials: Roles provide temporary credentials.
No Static Credentials: Unlike IAM users, roles don’t have static credentials.
Trust Policy: Determines which entities can assume the role.

Types of Roles:

1. Service Roles

Used by AWS services like EC2 or Lambda to perform actions on your behalf.

Example Role Template for EC2:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": "arn:aws:s3:::example-bucket"
    }
  ]
}

Trust Policy Example:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

2. Cross-Account Roles

Enable access across AWS accounts. Useful for centralizing management.

Trust Policy Example:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

3. Identity Provider Roles

Allow federated users (from SAML or OIDC providers) to access AWS resources.

Example:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:oidc-provider/accounts.google.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity"
    }
  ]
}

4. Task Roles

Used by ECS tasks to access AWS services.

Example:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::example-bucket/*"
    }
  ]
}

4. Trust Relationships

Trust relationships define who can assume a role. They are managed through trust policies, which specify the trusted principals.

Example of Trust Policy for Lambda:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

5. Roles vs Policies

Roles:

Act as an entity that can be assumed by trusted principals.
Provide temporary credentials.
Require a trust relationship.

Policies:

Define permissions (allow/deny actions).
Can be attached to users, groups, or roles.
Do not provide temporary credentials.

6. Common IAM Use Cases

1. Granting S3 Access to an EC2 Instance

Create an IAM role with S3 permissions.
Attach the role to the EC2 instance profile.

2. Cross-Account Access

Define a role in the target account with a trust relationship.
Allow the source account’s users to assume the role.

3. Federated Access

Configure an identity provider (e.g., Google Workspace).
Define roles for federated users with access policies.

7. Debugging IAM Issues

Scenario 1: Access Denied for S3

Check the role’s permissions.
Validate the trust relationship.
Inspect bucket policies and conditions.

Scenario 2: Cross-Account Role Fails

Ensure trust policy allows the source account.
Verify permissions in both accounts.

Scenario 3: ECS Task Role Error

Confirm the trust relationship includes ECS.
Test role assumption using AWS CLI.