Skip to content

IAM (Identity and Access Management)

1. Why This Service Exists (The Real Problem)

The Problem: In a physical data center, security was "Can you walk through the door?" or "Do you have the root password?". - Password Sharing Hell: Everyone shared root credentials. One person leaves, you change passwords everywhere. - All or Nothing: You couldn't say "Bob can restart the server but NOT read the database".

The Solution: A granular permission system where every API call is checked against a policy before execution. "Who are you?" (AuthN) and "Can you do this?" (AuthZ).

2. Mental Model (Antigravity View)

The Analogy: The Airport ID Badge & Zone System. - Principal (User/Role): The Person with a Badge. - Authentication: The scanner at the entrance proving you are who you say you are. - Authorization (Policy): The encoded chip on the badge that says "Allowed in Zone A (EC2), Denied in Zone B (Billing)". - Resource: The specific room (S3 Bucket) you are trying to enter.

One-Sentence Definition: The global gatekeeper that intercepts every AWS API call to verify if the requestor has permission to perform the action on the resource.

3. Core Components (No Marketing)

  1. User: A human (or app) with permanent credentials (Password / Access Keys). Anti-pattern for machines.
  2. Group: A collection of users (e.g., "Developers"). Assign permissions here, not on users.
  3. Role: An identity with no permanent password. It can be "assumed" temporarily by a User, a Service (EC2), or an External Identity (Google/GitHub).
  4. Policy: A JSON document defining permissions.
    • Effect: Allow/Deny
    • Action: s3:GetObject
    • Resource: arn:aws:s3:::my-bucket/*
  5. Principal: The entity making the request (e.g., role/MyEC2Role).

4. How It Works Internally (Simplified)

  1. Request: User Alice calls s3:ListBuckets.
  2. AuthN: AWS checks signatures (Access Key / Secret Key). Valid? -> Proceed.
  3. AuthZ (Evaluation Logic):
    • Start with Default Deny.
    • Is there an Explicit Deny anywhere? -> DENY. (Stop here).
    • Is there an Explicit Allow? -> ALLOW.
    • No Allow found? -> Implicit Deny.

5. Common Production Use Cases

  • Human Access: Developers log in via SSO (Identity Center) -> Assume Role DeveloperRole.
  • Machine Access: EC2/Lambda assumes a Role to read from DynamoDB.
  • Cross-Account Access: CI/CD pipeline in Account A assumes a Role in Account B to deploy code.

6. Architecture Patterns

The "Role Assumption" Pattern (Best Practice)

Don't create IAM Users for services. Do use Roles.

Flow: 1. Create Role AppRole with policy Allow S3 Read. 2. Pass Role to EC2 Instance Profile. 3. Application SDK calls sts:AssumeRole automatically to get temp credentials. 4. Credentials expire automatically (1-12 hours).

The "Least Privilege" Boundary

Requirement: Developers can create S3 buckets, but only if they tag them with CostCenter: Eng. Mechanism: Use Condition Keys in Policy. 

"Condition": {
    "StringEquals": { "aws:RequestTag/CostCenter": "Eng" }
}

7. IAM & Security Model

This IS the Security Model. IAM is the firewall for API calls.

Trust Relationships (The "Who" Policy): - Every Role has a "Trust Policy". It defines who can assume this role. - Bad Trust Policy: Principal: { "AWS": "*" } (Lets anyone in the world assume your role!). - Good Trust Policy: Principal: { "Service": "ec2.amazonaws.com" } (Only EC2 can assume).

Permissions Boundary: - A guardrail policy that limits the maximum permissions a user/role can ever have, regardless of future policies attached. Use this to prevent admins from creating "Super Admin" users.

8. Cost Model (Very Important)

  • Free: IAM is free. You are not charged for users, roles, or policies.
  • Cost of Failure: A leaked Access Key on GitHub can cost you $50,000 in mined crypto in 24 hours.
    • Prevention: Set up Cost Anomaly Detection and strict SCP (Service Control Policies) if using Organizations.

9. Common Mistakes & Anti-Patterns

  • Root User Usage: Logging in as the email address you signed up with. NEVER DO THIS. Lock away the root credentials physically.
  • Hardcoded Access Keys: Sticking AWS_ACCESS_KEY_ID in .env files and committing to Git. Disaster.
  • Star Policies: "Action": "*", "Resource": "*". This is "Admin Access". Only use for Admins.
  • Inline Policies: Embedding JSON directly in a Role instead of creating a Managed Policy. Makes reuse and audit impossible.

10. When NOT to Use This Service

  • Application Authentication: IAM is for AWS Resources. Do not use IAM Users to log users into your website. Use Amazon Cognito or Auth0.
  • OS Level Access: IAM doesn't inherently manage SSH keys (Linux users) unless you use SSM Session Manager (which uses IAM to control shell access).

11. Interview-Level Summary

  • Role vs User: User = Permanent credential (Human). Role = Temporary credential (Service/Machine).
  • Policy Structure: Effect (Allow/Deny), Action, Resource.
  • Evaluation: Explicit Deny > Explicit Allow > Default Deny.
  • Principal: Who is asking?
  • Cross Account: Role Assumption is the only way to access resources in another account securely.