IAM - Identity and Access Management

What you will learn

• What IAM is and why every AWS action passes through it
• How Users, Groups, and permissions are structured
• How to read and write IAM Policies in JSON
• Why IAM Roles exist and how AWS services use them securely
• MFA, password policy, access keys, and credential best practices
• The two audit tools that keep your account clean

Why this matters

Every single action in AWS - launching an EC2, reading an S3 file, deleting a database - goes through IAM first. Get IAM wrong and you either lock your team out or hand an attacker the keys to everything. This is not a one-time setup. IAM is something you audit, tighten, and maintain continuously. Engineers who treat it as a formality are the ones who wake up to compromised accounts

What is IAM and the Root User Problem

IAM (Identity and Access Management) is a global AWS service that controls two things for every single request made in your account:

IAM is not region-specific. An IAM user you create today works in Mumbai, Singapore, and Virginia equally.

When you first open an AWS account, you get a Root User - created automatically with your account email and password. Root has complete, unrestricted access to everything: billing, IAM, every service, every region. No IAM policy in the world can limit it.

⚠️ Security: Enable MFA on root immediately after account creation. Never create Access Keys for root. Never use it for daily work. Think of root like a master key to your entire office building - you keep it locked in a safe and only take it out in emergencies.

Users, Groups and How Permissions Flow

IAM Users represent one real person or one application. One person = one user. Always. Sharing users makes auditing impossible - if something goes wrong you cannot tell who did it.

Each IAM user gets:

• A username + password → for AWS Console (browser login)
• Access Key ID + Secret Access Key → for CLI and SDK (programmatic access)

IAM Groups are containers for users with the same job role. Attach a policy to the group once - everyone inside inherits it automatically. When Sneha joins as a tester, add her to the Testers group. When she leaves, remove her. No individual cleanup needed.

Key rules that catch people out:

• Groups contain users only — you cannot nest a group inside another group
• A user can belong to multiple groups — permissions from all groups combine
• A user can exist outside all groups — allowed but not recommended

How permissions flow from group to user:

📌 Remember: Always attach policies to Groups, not directly to individual users. It scales. When someone changes roles, just move them between groups - done. Individual user policies pile up silently and become impossible to audit.

IAM Policies - Reading and Writing Permissions

A Policy is a JSON document that defines exactly what actions are allowed or denied on which AWS resources. This is the actual engine behind every permission in AWS.

A real policy - read-only access to one S3 bucket:

This lets someone read payment logs but explicitly blocks any delete - even if another policy tries to allow it.

Every field explained:

📌 Remember: Effect: Deny always wins over Effect: Allow. If one policy allows an action and another denies it, Deny wins every time - no exceptions. This is called the explicit deny rule.

Policy inheritance - Charles gets permissions from two groups:

Three types of policies:

IAM Roles - Permissions for AWS Services

IAM Roles solve a different problem from users. AWS services like EC2, Lambda, and ECS often need to call other AWS services. How do you give an EC2 instance permission to read S3 without storing any credentials on it?

The wrong way - what beginners do:

The right way - IAM Roles:

User vs Role - the key difference:

Common roles you will create in every real project:

💡 Tip: If you are ever tempted to put an access key inside an EC2, Lambda, or Docker container — stop. Create a Role instead. AWS SDK automatically retrieves temporary credentials from the Role. No keys. No risk. No manual rotation.

Securing Access - MFA, Password Policy and Access Keys

MFA — Multi-Factor Authentication

MFA = something you know (password) + something you own (a device). Even if someone steals Priya's AWS password, they cannot log in without her phone.

MFA device options:

Password Policy

AWS lets you enforce password rules account-wide for all IAM users:

• Minimum length (12+ characters recommended)
• Require uppercase, lowercase, numbers, special characters
• Allow users to change their own passwords
• Force expiration every 90 days
• Prevent reuse of last N passwords

Set it once: IAM → Account Settings → Password Policy.

Access Keys - for CLI and SDK access

Access Keys are how the AWS CLI and SDK authenticate — they replace username/password for programmatic access.

Non-negotiable rules for access keys:

• Never commit to Git — scanners watch GitHub, GitLab, Bitbucket 24/7
• Never hardcode in application source code
• Never share with teammates — each person generates their own
• Deactivate immediately if you suspect a leak
• For EC2 and Lambda — never use keys at all, use Roles

Setting up AWS CLI:

Three ways to access AWS — when to use which:

💡 Tip: AWS CloudShell is a browser-based terminal inside the Console — pre-configured with your credentials, zero local setup. Perfect for quick commands when you're on someone else's machine.

IAM Security Audit Tools

Once teams grow, permissions drift silently. People leave but their users stay active. A service has permissions for 10 AWS APIs but only ever calls 2. AWS gives you two tools to catch this:

IAM Credentials Report — account-level snapshot:

• Downloads a CSV of every IAM user and their credential status
• Shows: password enabled, MFA enabled, access keys active/inactive, last login, last key use
• Use it to find: users inactive for 90+ days (probably left the company), unused access keys
• Location: IAM Dashboard → Credential Report → Download

IAM Access Advisor — user-level permission usage:

• Shows which AWS services a specific user or role actually accessed and when

• If Arjun has EC2, S3, RDS, Lambda permissions but only ever touched S3 in 90 days → remove the rest

• This is least privilege in practice, not just in theory

• Location: IAM → Users → Select user → Access Advisor tab

  Real example — trimming Arjun's permissions using Access Advisor:

  ◈ DIAGRAM

  Arjun currently has: EC2Full + S3Full + RDSFull + LambdaFull + CloudWatchFull

  Access Advisor shows:

  S3 → accessed 2 days ago

  CloudWatch → accessed 1 week ago

  EC2 → accessed 5 months ago

  RDS → never accessed

  Lambda → never accessed

  Action: Remove RDS and Lambda. Review EC2.

  Result: Smaller blast radius if Arjun's credentials are ever compromised.

📌 Remember: Credentials Report = audit the entire account at once. Access Advisor = trim permissions for one specific user or role. Run both monthly.

Hands-on Lab — Set Up IAM the Right Way

This is the exact setup every AWS account should have from day one.

1. Log into AWS Console as root → open IAM Dashboard
2. Enable MFA on root: IAM → Security recommendations → Add MFA → use Google Authenticator
3. Create your first IAM admin user: IAM → Users → Create user → attach AdministratorAccess → enable Console access with a strong password
4. Log out of root → log back in as your new IAM admin user → use this for all daily work
5. Create a Group: IAM → User Groups → Create group → name it Developers → attach AmazonEC2FullAccess and AmazonS3ReadOnlyAccess
6. Create test user arjun-dev → add to Developers group → verify combined permissions in the Permissions tab
7. Generate Access Key for arjun-dev: IAM → Users → arjun-dev → Security credentials → Create access key → choose CLI use case
8. On your terminal run aws configure → paste the access key and secret → set region ap-south-1
9. Test CLI: aws s3 ls and aws ec2 describe-instances
10. IAM Dashboard → Credential Report → Download → open CSV and review all users

Expected Result: Root is MFA-protected and unused. You have a working IAM admin user for daily work. A developer user with scoped group permissions exists. CLI access is configured and tested. You have read your first credentials report.