Introduction

AWS Identity and Access Management (IAM) is a fundamental service in AWS. If you open any book or read anything about security, you’ll like likely start by learning IAM. IAM is a service that helps you securely control access to AWS services and resources. The two fundamental components of IAM are policies and roles. While they are closely related and often used together, they serve distinct purposes. In this post, I’ll break down the differences between IAM policies and IAM roles, and how to effectively use them in your AWS environment.

What are IAM Policies?

Definition

IAM policies are JSON documents that define permissions for actions on AWS resources. They specify who can do what on which resources under what conditions.

Key Features

1. Statements: Each policy consists of one or more statements, which include:

   • Effect: Specifies whether the statement allows or denies access.

   • Action: Lists the actions that are allowed or denied.

   • Resource: Specifies the resources to which the actions apply.

   • Condition (Optional): Defines conditions for when the policy is in effect.

2. Types of Policies:

   • Managed Policies: AWS managed policies are pre-configured policies created and managed by AWS. Customer managed policies are created and managed by users.

   • Inline Policies: Policies that are directly embedded within IAM users, groups, or roles.

Example: IAM Policy

Here’s an example of a JSON IAM policy that grants read-only access to objects in a specific S3 bucket:

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

Use Cases

IAM policies are used to:

• Grant or restrict permissions to users, groups, or roles.

• Define granular access controls for specific actions and resources.

• Implement security best practices by following the principle of least privilege.

What are IAM Roles?

Definition

IAM roles are entities that define a set of permissions for making AWS service requests. Unlike IAM users, roles do not have permanent credentials. Instead, roles are assumed by trusted entities such as users, applications, or services.

Key Features

1. AssumeRole: Roles can be assumed by entities that are authorized to use the sts:AssumeRole API.

2. Temporary Security Credentials: When a role is assumed, AWS provides temporary security credentials (access key, secret key, and session token) for the duration of the session.

3. Trust Policy: Each role has an associated trust policy that specifies which entities can assume the role.

Example: IAM Role

Here’s an example of an IAM role trust policy that allows EC2 instances to assume the role:

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

And an example of an attached policy that grants the role permission to read objects from an S3 bucket:

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

Use Cases

IAM roles are used to:

• Allow EC2 instances to interact with other AWS services securely.

• Enable cross-account access for resources in different AWS accounts.

• Delegate access within an account without sharing long-term credentials.

• Assign permissions to AWS services like Lambda, ECS tasks, and CodeBuild.

Key Differences Between IAM Policies and Roles

Purpose

• IAM Policies: Define what actions are allowed or denied on which resources under specific conditions.

• IAM Roles: Define a set of permissions that can be assumed by trusted entities to perform actions on AWS resources.

Attachment

• IAM Policies: Can be attached to IAM users, groups, or roles.

• IAM Roles: Cannot be directly attached to users or groups; instead, they are assumed by trusted entities.

Credential Management

• IAM Policies: Do not provide credentials. They simply specify permissions.

• IAM Roles: Provide temporary security credentials when assumed.

Use Cases

• IAM Policies: Used to define permissions across the AWS account for various entities.

• IAM Roles: Used to grant temporary access to AWS resources, often for specific tasks or cross-account access.

Practical Example

Let’s consider a scenario where you have an EC2 instance that needs to read objects from an S3 bucket. Here’s how you might use IAM policies and roles:

1. Create an IAM Role:

   • Define a role with a trust policy that allows EC2 instances to assume the role.

   • Attach a policy to the role that grants s3:GetObject permission for the specific S3 bucket.

2. Attach the Role to the EC2 Instance:

   • When launching the EC2 instance, specify the IAM role. The instance will assume the role and receive temporary credentials.

3. Access S3 Bucket:

   • The EC2 instance uses the temporary credentials to access the S3 bucket according to the permissions defined in the attached policy.

Creating the IAM Role and Policy with AWS CLI

Here’s how you can create the IAM role and attach the policy using the AWS CLI:

Step 1: Create the IAM Role

aws iam create-role --role-name EC2S3ReadOnlyRole --assume-role-policy-document file://trust-policy.json

Step 2: Attach the Policy to the Role

aws iam put-role-policy --role-name EC2S3ReadOnlyRole --policy-name S3ReadOnlyPolicy --policy-document file://s3-read-only-policy.json

Step 3: Launch EC2 Instance with the IAM Role

When launching the EC2 instance, specify the IAM role EC2S3ReadOnlyRole.

Conclusion

Understanding the differences between AWS IAM policies and roles is important for implementing security controls in your AWS environment. Policies define permissions, while roles provide a way to assume those permissions temporarily. By leveraging both effectively, you can ensure secure and efficient access to your AWS resources.