AWS IAM explained, identities, roles, policies, attack paths
AWS Identity and Access Management (IAM) decides who can do what in your AWS account. Every API call passes through IAM. Your IAM design is your security posture: a permissive IAM design with perfect everything-else still loses, and a tight IAM design rescues a lot of other mistakes.
Why AWS IAM explained matters
Almost every documented AWS breach since 2018 has IAM at the centre, over-broad roles, AWS-managed policies attached to production workloads, IAM users with long-lived access keys committed to GitHub, or cross-account trust policies with `Principal: "*"`. IAM is where compromise turns into impact.
Common mistakes with AWS IAM explained
- Attaching `AdministratorAccess` to roles that need three actions.
- Using IAM users with long-lived access keys for CI/CD instead of OIDC + assumable roles.
- Cross-account trust policies that name `Principal: "*"` and rely solely on `sts:ExternalId`.
- Forgetting that `iam:PassRole` is what turns service-assumption into privilege escalation.
How attackers exploit AWS IAM explained
Public S3 → access key in object → attacker uses key → assumes role with `iam:*` → creates new admin role → persists as admin even after the original key is rotated. Every step is an IAM decision.