Deep Dive: AWS Identity and Access Management (IAM)

This study guide covers the fundamental and advanced concepts of IAM as required for professional-level architecture, focusing on identity management, permission policies, and security best practices.

---

Learning Objectives

After studying this guide, you should be able to:

• Distinguish between IAM Users and IAM Roles, specifically regarding credential longevity.
• Categorize IAM Policies into Identity-based (Managed vs. Inline) and Resource-based types.
• Implement the Principle of Least Privilege using specific JSON policy statements.
• Explain the role of MFA and IAM Groups in a scalable security strategy.
• Justify the use of temporary credentials for both human and machine identities.

---

Key Terms & Glossary

• IAM Identity: An IAM resource object (User, Group, or Role) used to identify and group.
• Principal: A person or application that can make a request for an action or operation on an AWS resource.
• Policy: A JSON document that defines permissions. Policies can be attached to identities or resources.
• MFA (Multi-Factor Authentication): A security system that requires more than one method of authentication to verify the user's identity.
• Trust Policy: A JSON policy document in which you define who is allowed to assume a role.
• Access Key: Long-lived credentials (Access Key ID and Secret Access Key) used for programmatic access.

---

The "Big Idea"

IAM is the gatekeeper of the AWS cloud. Its primary mission is to provide a centralized framework to answer two questions: "Who are you?" (Authentication) and "What are you allowed to do?" (Authorization). In complex organizations, the shift moves from managing individuals (Users) to managing functions and temporary access (Roles) to reduce the blast radius of credential leaks.

---

Formula / Concept Box

The Anatomy of a Policy Statement

Permissions are evaluated based on the interaction of several key elements within a JSON statement:

---

Hierarchical Outline

1. IAM Identities
   • IAM Users: Long-lived credentials; associated with one person/application.
   • IAM User Groups: Collections of users; used for easier permission management (inheritance).
   • IAM Roles: Temporary credentials via STS; can be assumed by users, services, or cross-account identities.
2. Permission Mechanisms (Policies)
   • Identity-Based: Attached to Users/Roles/Groups.
     • AWS Managed: Maintained by AWS (e.g., AdministratorAccess).
     • Customer Managed: Created by you for fine-grained control.
     • Inline: Embedded directly in a single identity.
   • Resource-Based: Attached to resources (e.g., S3 Bucket Policies).
3. Security Controls
   • MFA: Mandatory for root accounts and highly privileged users.
   • Least Privilege: Granting only the minimum permissions required for a task.

---

Visual Anchors

IAM Role Assumption Flow

Policy Evaluation Logic

This diagram represents the decision flow when AWS evaluates multiple policies.

\begin{tikzpicture}[node distance=2cm, every node/.style={rectangle, draw, fill=blue!10, text width=3cm, align=center, minimum height=1cm}] \node (start) {Start Request}; \node (deny) [below of=start] {Explicit Deny?}; \node (allow) [below of=deny] {Explicit Allow?}; \node (final_deny) [right of=deny, xshift=3cm, fill=red!20] {Final Decision: DENY}; \node (final_allow) [right of=allow, xshift=3cm, fill=green!20] {Final Decision: ALLOW};

\end{tikzpicture}

---

Definition-Example Pairs

• Term: Least Privilege

  • Definition: The practice of limiting access rights for users to the bare minimum permissions they need to perform their work.
  • Example: Instead of giving a developer s3:* access, you give them s3:GetObject only for the specific bucket used for their project.

• Term: Temporary Credentials

  • Definition: Short-term credentials (minutes to hours) provided by AWS STS that expire automatically.
  • Example: An EC2 instance using an IAM Role to fetch a configuration file from S3 without storing an access key on the disk.

---

Worked Examples

Analyzing an S3 Read-Only Policy

Consider the following JSON policy provided in the source material:

Breakdown:

1. Effect: Set to Allow, meaning it permits the listed actions.
2. Action: Uses wildcards (*). s3:Get* allows GetObject, GetObjectTagging, etc. s3:List* allows ListBucket, ListAllMyBuckets, etc.
3. Resource: Set to *, meaning this applies to every S3 bucket in the AWS account.
4. Security Assessment: While functional for a read-only auditor, this violates least privilege if the user only needs access to one specific bucket.

---

Checkpoint Questions

1. Question: Why are IAM Roles preferred over IAM Users for applications running on EC2?
   • Answer: Roles provide temporary credentials that rotate automatically, eliminating the need to manage and secure long-lived access keys on the instance.
2. Question: What happens if an Identity-based policy allows an action, but an Organizations SCP (Service Control Policy) denies it?
   • Answer: The action is denied. An explicit deny in any policy (Identity, Resource, or SCP) always overrides an allow.
3. Question: Can an IAM User belong to more than one IAM Group?
   • Answer: Yes, and they will inherit the permissions from all groups they are a member of.

---

Muddy Points & Cross-Refs

• Cross-Account Access: Users often confuse assuming a role in another account with resource-based policies.
  • Deep Dive Pointer: Look into Chapter 1 (as mentioned in source) for "Access Delegation" to understand the Trust Relationship required for cross-account roles.
• Managed vs. Inline: When to use which?
  • Rule of Thumb: Use Managed Policies for everything by default. Use Inline Policies only if you want a strict 1-to-1 relationship where deleting the identity must delete the permissions (rare in professional environments).

---

Comparison Tables

IAM Users vs. IAM Roles