Who Goes There? — IAM, Identity & Access Management on AWS Decoded

---

Episode 04: The gatekeeper of AWS — IAM. Everything about users, roles, policies, credentials, and how AWS decides who gets to do what.

---

Why IAM Exists

Every request made to AWS — whether from the Console, CLI, or an application — is ultimately an HTTPS API call. AWS needs to verify two things before honouring any request:

• Authentication — are you who you claim to be?
• Authorization — are you allowed to do what you're asking?

IAM (Identity and Access Management) is the AWS service that handles both. It is global (not tied to any region) and completely free.

---

The Root User — Powerful but Dangerous

When you create an AWS account, the first identity created is the root user. It has unrestricted access to every AWS service and billing setting — no policy can limit it.

Root user should only be used for a handful of specific tasks: changing account settings, closing the account, or restoring IAM access. Create an IAM admin user immediately and lock root credentials away.

The first thing to do on any new AWS account:

1. Enable MFA on the root user
2. Never create access keys for root
3. Create an IAM admin user and use that going forward

---

How AWS Processes Requests — SigV4

All AWS services are exposed as REST APIs over HTTPS. Directly calling these APIs requires SigV4 (Signature Version 4) — AWS's own cryptographic signing algorithm that proves a request came from a legitimate identity and hasn't been tampered with in transit.

Because implementing SigV4 manually is complex, AWS provides three access methods that handle signing automatically:

Access Method	Best for	Credentials used
AWS Management Console	Human operators, visual tasks	Username + Password + MFA
AWS CLI	Scripting, automation, terminal workflows	Access Keys
AWS SDK	Application code (Python, Java, Node.js etc.)	Access Keys or IAM Role

---

IAM Credentials

Username & Password

Used for Console access. Power users and admins should always have MFA (Multi-Factor Authentication) enabled alongside their password.

Access Keys

Used for programmatic access via CLI and SDK. An access key has two parts:

• Access Key ID — identifies which user or role is making the request
• Secret Access Key — a cryptographic secret used to sign the request

Access keys are long-term credentials — they do not expire unless rotated or deleted manually. This makes them higher risk than temporary credentials.

Best practice: use IAM roles wherever possible instead of access keys. If access keys are necessary, rotate them regularly and never embed them in application code or commit them to a repository.

Temporary Credentials

Generated by AWS STS (Security Token Service), temporary credentials consist of three parts:

Access Key ID  +  Secret Access Key  +  Session Token

They expire after a configured duration (default 1 hour, up to 12 hours) and cannot be renewed — a new set must be requested. This makes them significantly safer than long-term access keys.

---

IAM Policy — The Permission Engine

An IAM Policy is a JSON document that defines what actions are allowed or denied on which resources, for whom, and under what conditions.

A policy statement has up to six elements:

Element	Purpose	Required?
Sid	Optional identifier for the statement	No
Effect	Allow or Deny	Yes
Principal	Who the policy applies to (used in resource-based policies)	Depends
Action	Which AWS API actions are covered (s3:GetObject, ec2:StartInstances)	Yes
Resource	Which specific AWS resource via ARN (arn:aws:s3:::my-bucket/*)	Yes
Condition	Optional conditions that must be true for the policy to apply	No

How AWS Evaluates Policies

When any request hits AWS, the evaluation follows this order:

1. Explicit DENY anywhere → denied immediately (overrides everything)
2. Explicit ALLOW in an applicable policy → allowed
3. No matching rule → implicit DENY

A single explicit Deny beats any number of Allow statements. This is the most important rule in IAM policy evaluation.

Types of IAM Policies

1. Identity-Based Policies — attached to users, groups, or roles

Sub-type	Description	When to use
AWS Managed	Pre-built by AWS, read-only	Quick standard permissions
Customer Managed	Created by you, reusable across identities	Custom org-specific permissions
Inline	Embedded directly into one identity, deleted with it	Strict 1:1 permissions that must never be reused

2. Resource-Based Policies — attached directly to an AWS resource

	Identity-Based	Resource-Based
Attached to	User / Group / Role	AWS resource (S3, SQS, KMS)
Controls	What the identity can do	Who can access this resource
Cross-account	Via role assumption	Directly, without role assumption
Principal field	Not required	Required

Use resource-based policies when you need to grant cross-account access directly, or when the resource itself needs to control who can reach it (like an S3 bucket shared with another account).

---

IAM Groups

An IAM Group is a collection of IAM users who share the same permissions. Instead of attaching policies to each user individually, you:

1. Create a group (e.g. developers, devops-engineers, read-only-auditors)
2. Attach the appropriate policies to the group
3. Add users to the group — they inherit all group permissions automatically

Groups are for human users only. AWS services cannot be members of a group — that is what IAM Roles are for.

---

IAM Roles — The Right Way to Grant Access to Services

An IAM Role is an AWS identity that can be assumed temporarily by users, applications, or services to access AWS resources without using long-term credentials.

Unlike a user, a role has no permanent credentials — every time it is assumed, AWS STS issues a fresh set of temporary credentials that expire automatically.

Who can assume a role?

• AWS services — EC2 instances, Lambda functions, ECS tasks accessing other AWS services (S3, DynamoDB, SSM etc.)
• IAM users in the same or different accounts — for cross-account access
• External identities — users authenticated via an external identity provider (Google, Active Directory, Okta)

Why roles over access keys for services?

	Access Keys on EC2	IAM Role on EC2
Credential type	Long-term, manual rotation	Temporary, auto-rotated every hour
Risk if exposed	Permanent access until manually revoked	Expires automatically
Management overhead	High — must rotate manually	Zero — AWS handles it
Best practice	❌ Never	✅ Always

---

STS & Temporary Credentials in Depth

AWS STS (Security Token Service) is the engine behind every temporary credential in AWS. When a role is assumed, STS is what generates the short-lived credentials.

Two important STS APIs to know:

API	Used when
AssumeRoleWithSAML	Enterprise SSO via Active Directory, Okta, ADFS
AssumeRoleWithWebIdentity	Web/mobile apps via Google, Facebook, Cognito, GitHub

---

Identity Federation — SAML & OIDC

When users from outside AWS need access — corporate employees, mobile app users, or third-party systems — you use identity federation to let them assume IAM roles using their existing credentials.

	SAML 2.0	OIDC
Used for	Enterprise SSO	Modern web and mobile apps
Common providers	Active Directory, Okta, OneLogin	Google, Facebook, Cognito, GitHub
Token format	XML	JWT (JSON Web Token)
STS API called	AssumeRoleWithSAML	AssumeRoleWithWebIdentity
AWS use case	Corporate employees accessing AWS Console	App users assuming scoped roles

Neither type creates permanent IAM users — they federate through roles and receive temporary credentials from STS.

---

IAM Permission Boundary

A Permission Boundary sets the maximum permissions an identity can ever have — regardless of what their attached policies say.

Effective Permission = Identity Policy  ∩  Permission Boundary

Even if a policy grants full S3 access, a permission boundary restricting to read-only makes the effective permission read-only. Used by security teams to safely delegate IAM management to developers without risk of privilege escalation.

---

IAM Audit & Compliance Tools

Tool	What it does
IAM Credentials Report	Account-level report of all users and credential status
IAM Access Advisor	Shows last accessed time per service — helps remove unused permissions
IAM Access Analyzer	Identifies resources shared outside your account or org
AWS Trusted Advisor	Flags open root access, unused credentials, and security gaps

---

IAM Best Practices

1. Lock root credentials — enable MFA on root and never use it day to day
2. Never create access keys for root
3. Attach policies to groups, not individual users — cleaner, scalable
4. Use IAM roles for all AWS services — never embed access keys in code or EC2
5. Apply least privilege — start minimum, expand only when needed
6. Enable MFA for all privileged users
7. Rotate access keys regularly — or eliminate them in favour of roles
8. Use Customer Managed Policies over inline for reusability and auditability
9. Use IAM Access Advisor regularly to prune unused permissions
10. Use Permission Boundaries when delegating IAM admin rights to developers

---

Architecture at a Glance

AWS Account
└── IAM (Global, Free)
    │
    ├── Root User  (lock away — MFA only)
    │
    ├── IAM Users
    │   └── Added to IAM Groups
    │       └── Group has Customer Managed Policy attached
    │
    ├── IAM Roles  (assumed temporarily via STS)
    │   ├── EC2 Role  →  access S3, SSM, CloudWatch
    │   ├── Lambda Role  →  access DynamoDB, SQS
    │   └── Cross-account Role  →  assumed by user in another account
    │
    ├── Identity Federation
    │   ├── SAML (Okta, Active Directory)  →  STS AssumeRoleWithSAML
    │   └── OIDC (Google, Cognito)  →  STS AssumeRoleWithWebIdentity
    │
    └── IAM Tools
        ├── Credentials Report
        ├── Access Advisor
        └── Access Analyzer

---

Key Takeaways

• IAM is global and free — it is the authentication and authorization layer for every AWS request.
• Root user has unrestricted access — lock it away immediately and use IAM users instead.
• AWS Console uses username and password; CLI and SDK use access keys; services use IAM roles with temporary credentials.
• An IAM Policy has six elements: Sid, Effect, Action, Resource, Principal, and Condition. An explicit Deny always wins.
• IAM Groups are for human users — attach policies to groups, not individual users.
• IAM Roles issue temporary credentials via STS — always prefer roles over long-term access keys for services.
• SAML is for enterprise SSO; OIDC is for modern web and mobile app federation.
• Permission Boundaries cap the maximum effective permissions regardless of what identity policies allow.

---

This is Episode 04 of the Booting to Cloud — AWS Foundations series.

---

If this helped, drop a reaction and follow the series — more episodes dropping regularly.