Cloud IAM Fundamentals | Cloud Security

Identity and Access Management (IAM) is the security backbone of every cloud environment. Think of IAM as the bouncer at a club who checks your ID and decides which rooms you can enter. In cloud, every API request must answer two questions: "Who are you?" (authentication) and "What can you do?" (authorization).

IAM misconfigurations are the #1 cause of cloud breaches. Overly permissive policies, unused credentials, and confused deputy problems have led to massive data breaches. Understanding IAM deeply is essential for both defending and attacking cloud environments.

IAM ≠ Just Users

IAM covers users, groups, roles, service accounts, policies, and permissions. In cloud, "identity" often means a service or application, not just human users. A Lambda function or EC2 instance has an identity just like a user does.

Core IAM Concepts

1IAM Building Blocks:
2 
3PRINCIPALS (WHO can take action)
4─────────────────────────────────────────────────────────────────────
5Users           │ Human identities with long-term credentials
6Groups          │ Collections of users (inherit policies)
7Roles           │ Temporary credentials for users/services
8Service Accts   │ Non-human identities for applications
9Root/Admin      │ Full control over the account
10 
11POLICIES (WHAT actions are allowed/denied)
12─────────────────────────────────────────────────────────────────────
13Identity-based  │ Attached to users/groups/roles
14Resource-based  │ Attached to resources (S3 bucket policy)
15Permissions     │ Allow/Deny specific actions
16Conditions      │ When policy applies (IP, time, MFA)
17 
18RESOURCES (WHERE actions are performed)
19─────────────────────────────────────────────────────────────────────
20ARNs (AWS)      │ arn:aws:s3:::bucket-name/*
21Resource IDs    │ Unique identifiers for resources
22Wildcards       │ * = all resources (dangerous!)
23 
24ACTIONS (WHAT can be done)
25─────────────────────────────────────────────────────────────────────
26Service Actions │ s3:GetObject, ec2:StartInstances
27Wildcards       │ s3:* = all S3 actions (dangerous!)
28Granular        │ Specific action names

json

1606070;">// AWS IAM Policy Structure
2{
3  606070;">#a5d6ff;">"Version": "2012-10-17",
4  606070;">#a5d6ff;">"Statement": [
5    {
6      606070;">#a5d6ff;">"Sid": "AllowS3Read",
7      606070;">#a5d6ff;">"Effect": "Allow",           // or "Deny"
8      606070;">#a5d6ff;">"Action": [
9        606070;">#a5d6ff;">"s3:GetObject",
10        606070;">#a5d6ff;">"s3:ListBucket"
11      ],
12      606070;">#a5d6ff;">"Resource": [
13        606070;">#a5d6ff;">"arn:aws:s3:::my-bucket",
14        606070;">#a5d6ff;">"arn:aws:s3:::my-bucket/*"
15      ],
16      606070;">#a5d6ff;">"Condition": {
17        606070;">#a5d6ff;">"IpAddress": {
18          606070;">#a5d6ff;">"aws:SourceIp": "10.0.0.0/8"
19        }
20      }
21    }
22  ]
23}
24 
25606070;">// Breaking down the components:
26606070;">// Version     → Always use "2012-10-17" (current version)
27606070;">// Statement   → Array of permission rules
28606070;">// Sid         → Statement identifier (optional, for documentation)
29606070;">// Effect      → Allow or Deny the action
30606070;">// Action      → What API calls are permitted
31606070;">// Resource    → Which resources the action applies to
32606070;">// Condition   → Additional requirements (optional)

AWS IAM Deep Dive

bash

1606070;"># AWS IAM Identity Types
2 
3606070;"># 1. IAM Users - Human or service with long-term credentials
4aws iam create-user --user-name developer1
5aws iam create-access-key --user-name developer1
6606070;"># Returns: AccessKeyId + SecretAccessKey (guard these!)
7 
8606070;"># 2. IAM Groups - Collections of users
9aws iam create-group --group-name Developers
10aws iam add-user-to-group --group-name Developers --user-name developer1
11aws iam attach-group-policy --group-name Developers --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess
12 
13606070;"># 3. IAM Roles - Temporary credentials via AssumeRole
14aws iam create-role --role-name EC2-S3-Access --assume-role-policy-document file:606070;">//trust-policy.json
15606070;"># Roles are assumed by EC2, Lambda, other accounts, federated users
16 
17606070;"># 4. Service-Linked Roles - Auto-created for AWS services
18606070;"># Example: AWSServiceRoleForRDS for RDS
19 
20606070;"># Trust Policy (who can assume the role)
21{
22  606070;">#a5d6ff;">"Version": "2012-10-17",
23  606070;">#a5d6ff;">"Statement": [{
24    606070;">#a5d6ff;">"Effect": "Allow",
25    606070;">#a5d6ff;">"Principal": {
26      606070;">#a5d6ff;">"Service": "ec2.amazonaws.com"
27    },
28    606070;">#a5d6ff;">"Action": "sts:AssumeRole"
29  }]
30}

bash

1606070;"># AWS IAM Enumeration
2 
3606070;"># Who am I?
4aws sts get-caller-identity
5606070;"># Shows: UserId, Account, Arn
6 
7606070;"># List all users
8aws iam list-users
9 
10606070;"># List all roles
11aws iam list-roles
12 
13606070;"># Get user details
14aws iam get-user --user-name admin
15 
16606070;"># List attached policies for user
17aws iam list-attached-user-policies --user-name admin
18aws iam list-user-policies --user-name admin  606070;"># Inline policies
19 
20606070;"># Get policy document
21aws iam get-policy --policy-arn arn:aws:iam::123456789012:policy/MyPolicy
22aws iam get-policy-version --policy-arn arn:aws:iam::123456789012:policy/MyPolicy --version-id v1
23 
24606070;"># List access keys (check for old keys!)
25aws iam list-access-keys --user-name admin
26 
27606070;"># Check MFA status
28aws iam list-mfa-devices --user-name admin
29 
30606070;"># Get account password policy
31aws iam get-account-password-policy
32 
33606070;"># List all policies
34aws iam list-policies --scope Local  606070;"># Custom policies

Wildcards Are Dangerous

Policies with "Action": "*" or "Resource": "*" are overly permissive. Even "s3:*" on a specific bucket allows deletion. Always use least privilege - grant only what's needed.

Azure IAM (Entra ID)

1Azure Identity Model:
2 
3AZURE AD (Entra ID) - The Identity Provider
4─────────────────────────────────────────────────────────────────────
5Users               │ Human identities
6Groups              │ Security groups, Microsoft 365 groups
7Service Principals  │ Application identities
8Managed Identities  │ Auto-managed Azure service identities
9Guest Users         │ External users (B2B)
10 
11AZURE RBAC - Role-Based Access Control
12─────────────────────────────────────────────────────────────────────
13Scope Hierarchy:
14├── Management Group (multiple subscriptions)
15│   └── Subscription (billing boundary)
16│       └── Resource Group (logical container)
17│           └── Resource (individual resource)
18 
19Role Assignment = Security Principal + Role + Scope
20 
21Built-in Roles:
22├── Owner         │ Full access + can assign roles
23├── Contributor   │ Full access, can't assign roles
24├── Reader        │ View only
25├── User Access Administrator │ Manage user access
26└── Hundreds of service-specific roles...

bash

1606070;"># Azure CLI IAM Commands
2 
3606070;"># Login
4az login
5 
6606070;"># List subscriptions
7az account list
8 
9606070;"># Get current identity
10az account show
11 
12606070;"># List all users in Azure AD
13az ad user list
14 
15606070;"># Get user details
16az ad user show --id user@domain.com
17 
18606070;"># List groups
19az ad group list
20 
21606070;"># List service principals
22az ad sp list --all
23 
24606070;"># List role assignments
25az role assignment list --all
26 
27606070;"># Get role definition
28az role definition list --name 606070;">#a5d6ff;">"Contributor"
29 
30606070;"># Check permissions for a resource
31az role assignment list --scope /subscriptions/xxx/resourceGroups/myRG

Managed Identities

Azure Managed Identities eliminate the need for credentials in code. System-assigned identities are tied to a resource's lifecycle. User-assigned identities can be shared across resources. Always prefer managed identities over service principal secrets.

GCP IAM

1GCP IAM Model:
2 
3IDENTITIES (Members)
4─────────────────────────────────────────────────────────────────────
5User accounts       │ user:alice@gmail.com
6Service accounts    │ sa@project.iam.gserviceaccount.com
7Google Groups       │ group:team@googlegroups.com
8Cloud Identity      │ Organization-managed users
9allUsers           │ Anyone on internet (dangerous!)
10allAuthenticatedUsers│ Any logged-in Google account
11 
12ROLES
13─────────────────────────────────────────────────────────────────────
14Basic Roles (Avoid in production):
15├── roles/viewer    │ Read-only
16├── roles/editor    │ Read + modify (no IAM)
17└── roles/owner     │ Full control + IAM
18 
19Predefined Roles (Recommended):
20├── roles/storage.objectViewer
21├── roles/compute.instanceAdmin
22└── Thousands of granular roles...
23 
24Custom Roles:
25└── Project-specific permission bundles
26 
27RESOURCE HIERARCHY
28─────────────────────────────────────────────────────────────────────
29Organization
30└── Folder (optional)
31    └── Project
32        └── Resource

bash

1606070;"># GCP gcloud IAM Commands
2 
3606070;"># Get current identity
4gcloud auth list
5gcloud config get-value account
6 
7606070;"># List IAM policy for project
8gcloud projects get-iam-policy PROJECT_ID
9 
10606070;"># List service accounts
11gcloud iam service-accounts list
12 
13606070;"># Get service account keys (security risk!)
14gcloud iam service-accounts keys list --iam-account=SA@PROJECT.iam.gserviceaccount.com
15 
16606070;"># List roles
17gcloud iam roles list
18 
19606070;"># Describe a role
20gcloud iam roles describe roles/storage.objectViewer
21 
22606070;"># Test IAM permissions
23gcloud projects get-iam-policy PROJECT_ID   --flatten=606070;">#a5d6ff;">"bindings[].members"   --filter="bindings.members:user:alice@gmail.com"

IAM Misconfigurations

1Common IAM Misconfigurations:
2 
3OVERLY PERMISSIVE POLICIES
4─────────────────────────────────────────────────────────────────────
5Problem: {
6  606070;">#a5d6ff;">"Effect": "Allow",
7  606070;">#a5d6ff;">"Action": "*",
8  606070;">#a5d6ff;">"Resource": "*"
9}
10Risk: Full administrative access to everything
11Fix: Use least privilege, grant specific actions
12 
13CROSS-ACCOUNT TRUST TOO BROAD
14─────────────────────────────────────────────────────────────────────
15Problem: Trust policy allows any principal from another account
16{
17  606070;">#a5d6ff;">"Principal": {"AWS": "arn:aws:iam::999999999999:root"}
18}
19Risk: Any identity in that account can assume role
20Fix: Specify exact role ARN, add conditions (external ID)
21 
22NO MFA ON PRIVILEGED ACCOUNTS
23─────────────────────────────────────────────────────────────────────
24Problem: Admin/root accounts without MFA
25Risk: Password compromise = full account access
26Fix: Require MFA for all privileged operations
27 
28LONG-TERM CREDENTIALS EXPOSED
29─────────────────────────────────────────────────────────────────────
30Problem: Access keys in GitHub, CI/CD, environment variables
31Risk: Immediate account compromise
32Fix: Use roles, rotate keys, use secrets managers
33 
34INACTIVE USERS/KEYS
35─────────────────────────────────────────────────────────────────────
36Problem: Old employees' access not revoked, unused keys
37Risk: Lateral attack surface, credential stuffing
38Fix: Regular access reviews, automated cleanup
39 
40PRIVILEGE ESCALATION PATHS
41─────────────────────────────────────────────────────────────────────
42Problem: User can modify their own permissions
43{
44  606070;">#a5d6ff;">"Action": ["iam:CreatePolicyVersion", "iam:SetDefaultPolicyVersion"],
45  606070;">#a5d6ff;">"Resource": "*"
46}
47Risk: User escalates to admin
48Fix: Restrict IAM write permissions carefully

IAM Privilege Escalation

Over 20 AWS IAM permissions can lead to privilege escalation if granted carelessly. Examples: iam:CreatePolicyVersion, iam:AttachUserPolicy, iam:PassRole + lambda:CreateFunction. Always audit IAM carefully!

IAM Best Practices

1IAM Security Best Practices:
2 
3AUTHENTICATION
4─────────────────────────────────────────────────────────────────────
5✓ Enable MFA for all users (mandatory for privileged)
6✓ Use strong password policies
7✓ Implement SSO/federation where possible
8✓ Disable root account access keys
9✓ Regularly rotate credentials
10 
11AUTHORIZATION
12─────────────────────────────────────────────────────────────────────
13✓ Apply least privilege principle
14✓ Use managed policies over inline
15✓ Prefer roles over long-term credentials
16✓ Use conditions (IP, time, MFA) in policies
17✓ Separate duties (no single admin)
18 
19MONITORING
20─────────────────────────────────────────────────────────────────────
21✓ Enable CloudTrail (all regions)
22✓ Monitor IAM changes via alerts
23✓ Regular access reviews
24✓ Use IAM Access Analyzer
25✓ Alert on root account usage
26 
27HYGIENE
28─────────────────────────────────────────────────────────────────────
29✓ Remove unused users, roles, keys
30✓ Tag resources for ownership
31✓ Document permission requirements
32✓ Use service control policies (SCPs) for guardrails
33✓ Separate development and production accounts

IAM Assessment Methodology

IAM Security Assessment

Identity InventoryList all users, groups, roles, service accounts. Identify inactive identities and unused credentials.

Policy AnalysisReview attached policies for wildcards (*), overly broad permissions, and missing conditions. Check for privilege escalation paths.

Cross-Account TrustAudit trust relationships. Verify external ID conditions, check for overly permissive principals.

Credential HygieneCheck access key age, last used dates, MFA status. Identify long-term credentials in code/configs.

Monitoring GapsVerify CloudTrail/audit logs are enabled, alerting is configured for IAM changes, access analyzer is running.

Privilege Escalation TestingTest if current permissions allow escalation: creating policies, assuming roles, modifying resources.

Knowledge Check

Quick Quiz

Question 1 of 3

What is the difference between an IAM User and an IAM Role in AWS?

Challenges

Audit an IAM Policy

Challenge

🔥 intermediate

Review this IAM policy and identify all security issues: {"Effect":"Allow","Action":["s3:*","iam:CreateUser","iam:AttachUserPolicy"],"Resource":"*"}

Need a hint? (3 available)

Key Takeaways

IAM answers: Who are you? What can you do? On which resources?
Roles provide temporary credentials - prefer over long-term keys
Wildcards (*) in policies are dangerous - always use least privilege
Multiple IAM permissions enable privilege escalation - audit carefully
Enable MFA, especially on privileged accounts
Regular access reviews prevent credential sprawl

Related Lessons

Cloud Security Fundamentals

AWS IAM Attacks

Azure AD Attacks