Applying IAM Policies to Roles, Endpoints, and Services

This study guide focuses on the critical skill of securing AWS resources by applying granular Identity and Access Management (IAM) policies. This is a core competency for the AWS Certified Data Engineer – Associate exam, specifically regarding data privacy, governance, and authentication mechanisms.

Learning Objectives

Distinguish between different IAM policy types (identity-based, resource-based, and permissions boundaries).
Configure IAM roles for service-to-service communication using the principle of least privilege.
Implement specialized access controls like S3 Access Points and VPC Endpoints (PrivateLink).
Evaluate effective permissions when multiple policy types overlap.

Key Terms & Glossary

Principal: An entity (user, role, or account) that can perform actions on AWS resources.
IAM Role: An identity with specific permissions that can be assumed by anyone (users or services) who needs them, providing temporary security credentials.
Service-Linked Role: A unique type of IAM role that is linked directly to an AWS service and predefined by the service for its own use.
ARN (Amazon Resource Name): A standardized format to uniquely identify AWS resources across all of AWS.
S3 Access Point: A named network endpoint with a dedicated access policy that describes how data can be accessed using that endpoint.
AWS PrivateLink: Technology that provides private connectivity between VPCs and AWS services without exposing data to the internet.

The "Big Idea"

In a data engineering ecosystem, security is not just about "who" has access, but "how" and "from where" that access occurs. By combining IAM Roles (identities) with Resource-Based Policies (on the data itself) and Network Endpoints (the path to the data), you create a multi-layered defense. This "Defense in Depth" ensures that even if a credential is leaked, the data remains protected by network constraints and resource-level locks.

Formula / Concept Box

IAM Policy Structure

Every IAM policy statement contains these four core elements:

Element	Description	Example
Effect	Whether the statement allows or denies access.	`"Effect": "Allow"`
Action	The specific API operation(s) being permitted.	`"Action": "s3:GetObject"`
Resource	The specific AWS resource(s) the action applies to.	`"Resource": "arn:aws:s3:::my-bucket/*"`
Condition	Optional: When the policy is in effect.	`"Condition": {"IpAddress": {"aws:SourceIp": "1.2.3.4/32"}}`

Hierarchical Outline

IAM Policy Types
- Identity-Based: Attached to users/roles; defines what an identity can do.
- Resource-Based: Attached to resources (e.g., S3 buckets, SQS queues); defines who can access the resource.
- Permissions Boundaries: A managed policy used to set the maximum permissions that an identity-based policy can grant.
Access Delegation & Roles
- Service Roles: Assumed by AWS services (e.g., Lambda, EMR) to interact with other resources.
- Cross-Account Access: Using roles to allow a principal in Account A to access resources in Account B safely.
Modern S3 Security
- S3 Access Points: Simplifies managing data access for shared datasets; unique policies for different applications.
- Block Public Access: An account-level or bucket-level guardrail to prevent accidental exposure.
Network-Level IAM (Endpoints)
- Interface VPC Endpoints: Uses PrivateLink to keep traffic within the AWS backbone.
- Endpoint Policies: Resource-based policies attached to a VPC endpoint to control which principals can use it.

Visual Anchors

Policy Evaluation Logic

Loading Diagram...

S3 Access Point Architecture

\begin{tikzpicture}[node distance=2cm, every node/.style={fill=white, font=\small}] % Styles \tikzstyle{box} = [rectangle, draw, minimum width=2.5cm, minimum height=1cm, text centered]

% Nodes \node (user1) [box] {Finance App}; \node (ap1) [box, right of=user1, xshift=2cm] {Finance Access Point}; \node (user2) [box, below of=user1] {Analytics App}; \node (ap2) [box, right of=user2, xshift=2cm] {Analytics Access Point}; \node (s3) [box, right of=ap1, yshift=-1cm, xshift=2cm, minimum height=3cm, fill=orange!20] {S3 Bucket};

% Connections \draw[->, thick] (user1) -- node[above] {IAM: Role A} (ap1); \draw[->, thick] (ap1) -- node[above] {Read Only} (s3); \draw[->, thick] (user2) -- node[above] {IAM: Role B} (ap2); \draw[->, thick] (ap2) -- node[above] {Read/Write} (s3); \end{tikzpicture}

Definition-Example Pairs

Service-Linked Role
- Definition: A role predefined by an AWS service that includes all the permissions the service requires to call other AWS services on your behalf.
- Example: An AWSServiceRoleForAutoScaling allows EC2 Auto Scaling to launch or terminate instances when your scaling policies are triggered.
Least-Privilege Principle
- Definition: Granting only the specific permissions required to perform a task and nothing more.
- Example: Instead of granting s3:* to a Lambda function, you grant s3:GetObject and restrict the resource to arn:aws:s3:::my-app-data/logs/*.

Worked Examples

Scenario: Cross-Account S3 Access

Goal: An EC2 instance in Account A (Dev) needs to read data from an S3 bucket in Account B (Production).

Step 1: Create a Role in Account B (Production) Define a Trust Policy that allows Account A to assume the role.

json

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

Step 2: Attach Permissions to the Role in Account B Attach a policy allowing s3:GetObject on the specific bucket.

Step 3: Grant Permission in Account A (Dev) Attach an identity-based policy to the EC2 instance profile in Account A allowing it to call sts:AssumeRole on the ARN of the role created in Step 1.

Checkpoint Questions

Can a Permissions Boundary grant access to a resource if the Identity-based policy is missing?
What is the main advantage of using an S3 Access Point over a single large bucket policy for a shared dataset?
Why should you avoid using long-term IAM user credentials for application authentication?

▶View Answers

No. Permissions boundaries only limit the maximum permissions; they cannot grant access on their own.
It prevents a single bucket policy from becoming overly complex and reaching the size limit as more users/applications are added.
Long-term credentials (access keys) increase the risk of permanent compromise if leaked; roles use temporary credentials that expire automatically.

Comparison Tables

AWS Managed vs. Customer Managed Policies

Feature	AWS Managed	Customer Managed
Creation	Created and maintained by AWS.	Created and maintained by you.
Editability	Cannot be edited.	Fully customizable.
Updates	AWS adds new permissions automatically.	You must update permissions manually.
Scope	Broad (e.g., `ReadOnlyAccess`).	Precise (Least Privilege).

Muddy Points & Cross-Refs

Service Role vs. Service-Linked Role: This is a common point of confusion. A Service Role is a standard IAM role you create for a service to assume. A Service-Linked Role is a special role owned and managed by the service itself—you cannot modify its permissions.
Public Access: Remember that S3 Block Public Access settings override any bucket policies or ACLs that attempt to grant public access.
Cross-Ref: For more on auditing these permissions, study AWS CloudTrail and IAM Access Analyzer (which checks for unintended external access).