IAM roles concept in AWS - Commands & Configuration

Introduction

Sometimes, you want a service or user to do things in your cloud account without sharing your password. IAM roles let you give permissions safely to services or people for a short time without sharing long-term credentials.

When an application running on a server needs to access cloud storage without embedding passwords.

When you want to allow a user from another AWS account to access your resources temporarily.

When a Lambda function needs permission to read from a database.

When you want to give temporary access to a developer without sharing your main credentials.

When an EC2 instance needs to upload files to S3 securely.

Config File - trust-policy.json

trust-policy.json

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

This JSON file defines who can use the role. Here, it allows EC2 instances to assume the role and get permissions attached to it.

Version: The policy language version.

Statement: The rules. This one allows EC2 service to assume the role.

Commands

Create a new IAM role named MyEC2Role with a trust policy that allows EC2 instances to use it.

Terminal

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

Expected Output

{

    "Role": {

        "Path": "/",

        "RoleName": "MyEC2Role",

        "RoleId": "AROAJEXAMPLEID",

        "Arn": "arn:aws:iam::123456789012:role/MyEC2Role",

        "CreateDate": "2024-06-01T12:00:00Z",

        "AssumeRolePolicyDocument": "{...}"

    }

}

→

--role-name - Sets the name of the new role.

→

--assume-role-policy-document - Specifies the trust policy JSON file.

Attach a policy to the role that allows read-only access to Amazon S3 buckets.

Terminal

aws iam attach-role-policy --role-name MyEC2Role --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

Expected Output

No output (command runs silently)

→

--role-name - Specifies which role to attach the policy to.

→

--policy-arn - Specifies the Amazon Resource Name of the policy to attach.

Check which policies are attached to the role to confirm the permissions.

Terminal

aws iam list-attached-role-policies --role-name MyEC2Role

Expected Output

{

    "AttachedPolicies": [

        {

            "PolicyName": "AmazonS3ReadOnlyAccess",

            "PolicyArn": "arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess"

        }

    ]

}

→

--role-name - Specifies the role to list policies for.

Key Concept

If you remember nothing else from this pattern, remember: IAM roles let services or users get temporary permissions safely without sharing passwords.

Common Mistakes

Not setting the correct trust policy to allow the service to assume the role.

Without the right trust policy, the service cannot use the role, so permissions won't work.

Always create or update the trust policy to include the correct service or user that needs the role.

Attaching no policies or wrong policies to the role.

The role has no permissions or insufficient permissions to perform actions.

Attach the exact policies that grant the needed permissions for the role's purpose.

Trying to use the role without configuring the service (like EC2) to assume it.

The service won't automatically get the role's permissions without proper configuration.

Assign the IAM role to the service instance or resource properly, for example, when launching an EC2 instance.

Summary

Create an IAM role with a trust policy that defines who can use it.

Attach permission policies to the role to grant needed access.

Verify attached policies to ensure the role has correct permissions.

Practice

1. What is the main purpose of an IAM role in AWS?

easy

A. To monitor network traffic

B. To store user passwords securely

C. To create virtual machines

D. To grant permissions to entities without sharing long-term credentials

Solution

1. Step 1: Understand IAM role purpose

   An IAM role allows AWS entities to assume permissions temporarily without needing permanent credentials like passwords.

2. Step 2: Compare options

   Only To grant permissions to entities without sharing long-term credentials correctly describes this purpose. Options B, C, and D describe unrelated AWS features.

3. Final Answer:

   To grant permissions to entities without sharing long-term credentials -> Option D

4. Quick Check:

   IAM roles = temporary permissions without passwords [OK]

Hint: Roles give permissions without passwords or keys [OK]

Common Mistakes:

• Confusing roles with user accounts
• Thinking roles store passwords
• Mixing roles with AWS services like EC2

2. Which of the following is the correct way to specify a trust policy for an IAM role?

easy

A. { "Statement": [{ "Effect": "Allow", "Principal": { "Service": "lambda.amazonaws.com" }, "Action": "iam:PassRole" }] }

B. { "Statement": [{ "Effect": "Allow", "Principal": { "Service": "ec2.amazonaws.com" }, "Action": "sts:AssumeRole" }] }

C. { "Statement": [{ "Effect": "Allow", "Principal": { "User": "admin" }, "Action": "iam:CreateUser" }] }

D. { "Statement": [{ "Effect": "Deny", "Principal": { "AWS": "*" }, "Action": "sts:AssumeRole" }] }

Solution

1. Step 1: Identify trust policy structure

   A trust policy allows a trusted entity (like EC2) to assume the role using sts:AssumeRole action.

2. Step 2: Check each option

   { "Statement": [{ "Effect": "Allow", "Principal": { "Service": "ec2.amazonaws.com" }, "Action": "sts:AssumeRole" }] } correctly allows EC2 service to assume the role. { "Statement": [{ "Effect": "Deny", "Principal": { "AWS": "*" }, "Action": "sts:AssumeRole" }] } denies all, which is invalid for trust. { "Statement": [{ "Effect": "Allow", "Principal": { "User": "admin" }, "Action": "iam:CreateUser" }] } uses wrong action and principal. { "Statement": [{ "Effect": "Allow", "Principal": { "Service": "lambda.amazonaws.com" }, "Action": "iam:PassRole" }] } uses wrong action (iam:PassRole) for trust.

3. Final Answer:

   { "Statement": [{ "Effect": "Allow", "Principal": { "Service": "ec2.amazonaws.com" }, "Action": "sts:AssumeRole" }] } -> Option B

4. Quick Check:

   Trust policy must allow sts:AssumeRole to a service [OK]

Hint: Trust policy uses sts:AssumeRole with service principal [OK]

Common Mistakes:

• Using iam:PassRole instead of sts:AssumeRole
• Denying all principals in trust policy
• Specifying user instead of service in Principal

3. Given this IAM role trust policy snippet:

{ "Statement": [{ "Effect": "Allow", "Principal": { "Service": "lambda.amazonaws.com" }, "Action": "sts:AssumeRole" }] }

Which AWS service can assume this role?

medium

A. AWS Lambda functions

B. Amazon EC2 instances

C. Amazon S3 buckets

D. AWS IAM users

Solution

1. Step 1: Read the Principal service

   The Principal is "lambda.amazonaws.com", which means AWS Lambda service is trusted.

2. Step 2: Match service to options

   AWS Lambda functions matches AWS Lambda functions. EC2, S3, and IAM users are different entities and not trusted here.

3. Final Answer:

   AWS Lambda functions -> Option A

4. Quick Check:

   Principal service = lambda.amazonaws.com means Lambda [OK]

Hint: Principal service name shows who can assume role [OK]

Common Mistakes:

• Confusing service names like ec2.amazonaws.com vs lambda.amazonaws.com
• Thinking S3 buckets can assume roles
• Assuming IAM users are trusted by default

4. You created an IAM role with this trust policy:

{ "Statement": [{ "Effect": "Allow", "Principal": { "Service": "ec2.amazonaws.com" }, "Action": "iam:PassRole" }] }

Why can't EC2 instances assume this role?

medium

A. Because the Effect should be Deny

B. Because the Principal service is incorrect

C. Because the action should be sts:AssumeRole, not iam:PassRole

D. Because EC2 instances cannot assume roles

Solution

1. Step 1: Identify the required action in trust policy

   The trust policy must allow the action sts:AssumeRole for the trusted entity to assume the role.

2. Step 2: Analyze the given policy

   The policy uses iam:PassRole, which is incorrect for trust. This prevents EC2 from assuming the role.

3. Final Answer:

   Because the action should be sts:AssumeRole, not iam:PassRole -> Option C

4. Quick Check:

   Trust policy action must be sts:AssumeRole [OK]

Hint: Trust policy action must be sts:AssumeRole [OK]

Common Mistakes:

• Using iam:PassRole instead of sts:AssumeRole
• Changing Effect to Deny by mistake
• Believing EC2 cannot assume roles

5. You want to allow an AWS Lambda function to assume an IAM role that grants access to S3 buckets. Which two policies must you configure correctly to make this work?

hard

A. A trust policy allowing lambda.amazonaws.com to assume the role and an IAM permissions policy granting S3 access

B. A trust policy allowing s3.amazonaws.com to assume the role and an IAM permissions policy granting Lambda execution

C. An IAM user policy granting Lambda permissions and a trust policy allowing EC2 to assume the role

D. A permissions policy granting S3 access and a trust policy denying all principals

Solution

1. Step 1: Identify trust policy requirements

   The trust policy must allow the Lambda service (lambda.amazonaws.com) to assume the role.

2. Step 2: Identify permissions policy requirements

   The role's permissions policy must grant access to S3 buckets for the Lambda function.

3. Step 3: Evaluate options

   A trust policy allowing lambda.amazonaws.com to assume the role and an IAM permissions policy granting S3 access correctly pairs the trust policy for Lambda and permissions for S3. Other options have incorrect principals or deny access.

4. Final Answer:

   A trust policy allowing lambda.amazonaws.com to assume the role and an IAM permissions policy granting S3 access -> Option A

5. Quick Check:

   Trust policy + permissions policy = role works [OK]

Hint: Trust policy for who assumes; permissions policy for what they can do [OK]

Common Mistakes:

• Allowing wrong service in trust policy
• Confusing permissions policy with trust policy
• Denying all principals in trust policy