Mastering AWS IAM Roles: A Study Guide for Data Engineers

This guide covers the critical aspects of Identity and Access Management (IAM) roles, specifically focused on setting up secure access for services like AWS Lambda, API Gateway, and automated deployments via the CLI and CloudFormation.

Learning Objectives

After studying this guide, you will be able to:

• Define the structure and purpose of an IAM role compared to a user.
• Configure trust policies and permissions policies for service-to-service access.
• Implement least-privileged access for AWS Lambda and API Gateway.
• Setup the AWS CLI using temporary and long-term credentials.
• Apply IAM best practices within a Data Engineering context.

Key Terms & Glossary

• IAM Role: An identity that you can create in your account that has specific permissions but no long-term credentials (like a password or access keys).
• Trust Policy: A JSON document that defines which principals (services, accounts, or users) are allowed to assume the role.
• Permissions Policy: A document (usually JSON) that defines what actions the identity can perform on which resources.
• Principal: The entity that is allowed to assume a role (e.g., lambda.amazonaws.com).
• Least Privilege: The security principle of granting only the minimum permissions necessary to perform a task.
• STS (Security Token Service): The AWS service that grants temporary security credentials when a role is assumed.

The "Big Idea"

In AWS, humans use Users, but processes and services use Roles. Instead of hardcoding credentials into a Lambda function or an EC2 instance, you assign the service a "hat" (the Role) that it puts on to gain temporary permissions. This eliminates the risk of leaked long-term secrets and simplifies security management at scale.

Formula / Concept Box

Anatomy of an IAM Policy Statement

Hierarchical Outline

1. IAM Role Fundamentals
   • Credential-less Access: Roles do not have passwords/keys; they use temporary tokens.
   • Assumption: The process of an entity taking on the permissions of a role.
2. The Two Pillars of a Role
   • Trust Relationship: "Who can use me?"
   • Permissions Boundary: "What can I do once I've assumed the role?"
3. Service-to-Service Integration
   • Lambda: Requires an Execution Role to access S3, DynamoDB, or RDS.
   • API Gateway: Needs roles to push logs to CloudWatch or invoke Lambda.
4. Programmatic Access
   • AWS CLI: Setup via aws configure (requires Access Key ID and Secret Access Key).
   • CloudFormation: Uses a Service Role to provision resources on your behalf.

Visual Anchors

Role Assumption Flow

Relationship Architecture

\begin{tikzpicture}[node distance=2cm, every node/.style={rectangle, draw, rounded corners, minimum width=3cm, minimum height=1cm, align=center}] \node (User) {IAM User / Service}; \node (Role) [right of=User, xshift=3cm] {IAM Role}; \node (Trust) [above of=Role] {Trust Policy$Who can assume?)}; \node (Perm) [below of=Role] {Permissions Policy$What can it do?)}; \node (Res) [right of=Role, xshift=3cm] {AWS Resource$S3, Redshift)};

\end{tikzpicture}

Definition-Example Pairs

• Trust Policy
  • Definition: A policy that defines which entity can assume the role.
  • Example: A Lambda function's trust policy must include "Service": "lambda.amazonaws.com" to allow Lambda to take on the role.
• Execution Role
  • Definition: A specific type of role assigned to a compute resource (Lambda, EC2) to allow it to interact with other AWS services.
  • Example: An ETL Lambda function assigned a role with s3:PutObject permission to save transformed Parquet files.

Worked Examples

Case: Lambda to RDS Access

Scenario: You have a Lambda function that needs to write data to an RDS instance.

1. Create Role: Create a role named LambdaRDSWriteRole.
2. Trust Policy:
   jsonCopy

   { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "lambda.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }
3. Permissions Policy: Attach a policy allowing rds-db:connect.
4. Security Group: Update the RDS Security Group to allow inbound traffic from the Lambda's Security Group.

Checkpoint Questions

1. What are the four pieces of information required by the aws configure command?
2. What is the main difference between an IAM User and an IAM Role regarding credentials?
3. True or False: A Trust Policy defines which resources a role can access.
4. Which AWS service provides the temporary credentials for a role?

[!TIP] Answers:

1. Access Key ID, Secret Access Key, Default Region, Default Output Format.
2. Users have long-term credentials; Roles use temporary security tokens.
3. False (That is the Permissions Policy; the Trust Policy defines who can assume it).
4. AWS STS (Security Token Service).

Comparison Tables

IAM User vs. IAM Role

Muddy Points & Cross-Refs

• Inline vs. Managed Policies: Managed policies can be attached to multiple roles. Inline policies are strictly bound to one role. Use Managed Policies for scalability.
• PassRole Permission: Often confused with AssumeRole. iam:PassRole is the permission a user needs to assign a role to a service (like giving a role to a Lambda function).
• Cross-Account Access: To allow Account B to access Account A, Account A creates a role with a trust policy pointing to Account B's ID. Account B then assumes that role.