IAM: Identity & Access Management

Chapter 1 named "your own IAM users, roles & permissions" as squarely your side of the shared responsibility model. This chapter covers exactly that — IAM (Identity and Access Management), the real AWS service controlling who, and what, can do what, to which resources, across your entire account.

The Root Account — and Why You Don't Use It Day to Day

Every AWS account has exactly one real root user, created when the account itself was created, with unlimited, unrestricted access to everything — including the ability to close the account or change its own billing. AWS's own real, standard guidance is to lock this account down immediately (a strong password, MFA enabled) and then never use it for everyday work. Every real task after that first setup should run through a separate, individually named IAM identity instead — so that if any single credential is ever compromised, the damage is bounded to whatever that one identity was actually permitted to do.

Users, Groups, Roles & Policies

• IAM User — a real, individual identity (a person or an application) with its own long-term credentials (a password for console access, and/or access keys for programmatic access).
• IAM Group — a real, named collection of users. You attach permissions to the group once, and every user in it inherits them — the standard way to manage permissions for a whole team rather than one user at a time.
• IAM Role — genuinely different from a user: a role has no long-term credentials of its own. It's assumed temporarily — by a real person, by an AWS service (an EC2 instance, a Lambda function), or by another AWS account — and grants only short-lived, automatically expiring credentials for the duration it's assumed.
• IAM Policy — a real JSON document defining exactly what's allowed or denied. Policies attach to users, groups, or roles, and are what actually grant (or restrict) permission — a user or role with no policies attached can do essentially nothing.

A Real Policy Document

Every real IAM policy statement has the same four real building blocks: an Effect (Allow or Deny), an Action (the specific API calls it applies to, like s3:GetObject), a Resource (which specific thing it applies to, by ARN), and optionally a Condition (narrowing it further — e.g. only from a specific IP range, or only with MFA present).

The Principle of Least Privilege

A policy should grant exactly the permissions a real task needs, and nothing more. This is not just a security nicety — it's the direct practical guard against exactly the kind of failure Chapter 1's own shared-responsibility warning described: a resource or credential with far broader permissions than it actually needs becomes a far bigger real liability if it's ever compromised.

Multi-Factor Authentication (MFA)

MFA requires a second, real proof of identity beyond a password — a time-based one-time code from an authenticator app, or a physical hardware key — before a sign-in (or, via a policy Condition, before a specific sensitive action) is allowed to proceed. AWS's own real, standard recommendation is MFA on the root account without exception, and strongly encouraged for every IAM user with console access.

A Real Case Study: The 2019 Capital One Breach

This is a real, documented, large-scale illustration of Chapter 1's own shared responsibility model in practice: AWS's own infrastructure was not the point of failure — a customer-side misconfiguration was. Getting IAM roles, policies, and least-privilege access right isn't an abstract best practice; it's the exact category of control that determines how much real damage a single misconfiguration like this one can actually do.

Users, Groups, Roles & Policies at a Glance

Hands-On Exercises