IAM & Identity

The cheat table: AAD → IAM

The IAM mental model

Every IAM evaluation answers one question: "Can principal perform action on resource, under these conditions?"

Users vs Roles (the big one)

Side-by-side: workload identity

"How does my code on a VM/container get credentials to talk to other services?" is where the Azure-AWS gap is most visible.

# 1. Enable managed identity on the VM
az vm identity assign \
  --name myvm \
  --resource-group rg-app

# 2. Grant it permissions
az role assignment create \
  --assignee-object-id <principal-id> \
  --role "Storage Blob Data Reader" \
  --scope "/subscriptions/.../mystg"

# 3. Code on the VM "just works"
#    SDK auto-discovers credentials
#    from IMDS endpoint

# 1. Create a role that EC2 can assume
aws iam create-role \
  --role-name MyAppRole \
  --assume-role-policy-document file://trust.json

# 2. Attach permissions
aws iam attach-role-policy \
  --role-name MyAppRole \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

# 3. Attach role to instance via instance profile
aws ec2 associate-iam-instance-profile \
  --instance-id i-1234 \
  --iam-instance-profile Name=MyAppRole

# Code "just works" - SDK pulls creds
# from IMDSv2 endpoint http://169.254.169.254

Conceptually identical end-state, but AWS makes the role visible as a thing you can reuse. The same MyAppRole can be assumed by ten different EC2 instances, by Lambda functions, or by your laptop (if you allow it in the trust policy).

Same idea in Terraform

resource "azurerm_user_assigned_identity" "app" {
  name                = "app-mi"
  resource_group_name = "rg-app"
  location            = "eastus"
}

resource "azurerm_role_assignment" "app_storage" {
  scope                = azurerm_storage_account.s.id
  role_definition_name = "Storage Blob Data Reader"
  principal_id         = azurerm_user_assigned_identity.app.principal_id
}

resource "aws_iam_role" "app" {
  name = "app-role"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect = "Allow"
      Principal = { Service = "ec2.amazonaws.com" }
      Action = "sts:AssumeRole"
    }]
  })
}

resource "aws_iam_role_policy_attachment" "app_s3" {
  role       = aws_iam_role.app.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess"
}

Identity- vs resource-based policies

This is the concept that has no direct AAD analog. AAD permissions are almost always attached to the identity. AWS lets you attach permissions to either side - and many resources can be granted access without touching the requester's identity at all.

Identity-based policy: attached to who's asking

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:ListBucket"],
    "Resource": [
      "arn:aws:s3:::reports-bucket",
      "arn:aws:s3:::reports-bucket/*"
    ]
  }]
}

Attached to alice (user) or EC2-S3-Reader (role). It grants alice the ability to read from that specific bucket.

Resource-based policy: attached to the thing being touched

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::222222222222:user/alice" },
    "Action": ["s3:GetObject", "s3:ListBucket"],
    "Resource": [
      "arn:aws:s3:::reports-bucket",
      "arn:aws:s3:::reports-bucket/*"
    ]
  }]
}

Note the new Principal field. The bucket itself maintains a list of who's allowed in. This makes cross-account access possible without sharing credentials - account A's bucket can list account B's role as a principal, and IAM resolves it without anyone needing dual identities.

Which services support resource-based policies?

Trust policies and sts:AssumeRole

Every IAM role has two policies hanging off it:

Trust policy examples

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Service": "ec2.amazonaws.com" },
    "Action": "sts:AssumeRole"
  }]
}

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::111111111111:root" },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": { "sts:ExternalId": "shared-secret-for-confused-deputy" },
      "Bool": { "aws:MultiFactorAuthPresent": "true" }
    }
  }]
}

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Federated": "arn:aws:iam::123:oidc-provider/token.actions.githubusercontent.com" },
    "Action": "sts:AssumeRoleWithWebIdentity",
    "Condition": {
      "StringEquals": {
        "token.actions.githubusercontent.com:sub": "repo:my-org/my-repo:ref:refs/heads/main"
      }
    }
  }]
}

The assume-role flow

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principle": { "Service": "lambda.amazonaws.com" },
    "Action": "sts:AssumeRole"
  }]
}

Assume a role from your laptop

# Either via profile (we saw this in chapter 1):
aws s3 ls --profile prod-deploy   # silently runs sts:AssumeRole

# Or explicitly:
aws sts assume-role \
  --role-arn arn:aws:iam::333333333333:role/DeployerRole \
  --role-session-name "sunilt-cli-session"

# Returns AccessKeyId, SecretAccessKey, SessionToken, Expiration
# Export these as env vars and you're now acting as the role

How a request gets evaluated

Every AWS API call goes through the same decision tree. Memorize it - 90% of "why is access denied?" investigations end here.

Permission boundaries

A permission boundary is a cap on what an identity can do, regardless of its attached policies. Common use case: a developer can create IAM roles for their app, but the roles they create can never exceed the boundary's allow list. This is how you safely delegate IAM-creation rights.

Workload identity preview (IRSA)

Chapter 10 deep-dives EKS. But it's worth previewing the workload-identity pattern now because it's the cleanest example of how IAM roles + OIDC trust come together.

Try it: build a role and assume it

aws sts get-caller-identity
# Note the "Arn" value. Example: arn:aws:sts::123456789012:assumed-role/DeveloperAccess/sunilt

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::123456789012:role/aws-reserved/sso.amazonaws.com/AWSReservedSSO_DeveloperAccess_*" },
    "Action": "sts:AssumeRole"
  }]
}

aws iam create-role \
  --role-name PlaygroundReader \
  --assume-role-policy-document file://trust.json

aws iam attach-role-policy \
  --role-name PlaygroundReader \
  --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess

aws sts assume-role \
  --role-arn arn:aws:iam::123456789012:role/PlaygroundReader \
  --role-session-name lab-session

# Exports the temp creds:
export AWS_ACCESS_KEY_ID=ASIA...
export AWS_SECRET_ACCESS_KEY=...
export AWS_SESSION_TOKEN=...

# Re-check identity - you're now the role
aws sts get-caller-identity
# Arn: arn:aws:sts::123456789012:assumed-role/PlaygroundReader/lab-session

unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN

aws iam detach-role-policy --role-name PlaygroundReader \
  --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess
aws iam delete-role --role-name PlaygroundReader

Quick check

Gotchas for Azure devs

Project Compass: lay the IAM foundation

Picking up from chapter 1, where you set up the compass CLI profile. In this chapter's slice we create the IAM role that gfn-reports will eventually use. The role starts empty - no permissions yet. Future chapters add S3, DynamoDB, SQS, and KMS permissions as those services come online.

cat > /tmp/compass-trust.json <<'EOF'
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Service": "lambda.amazonaws.com" },
    "Action": "sts:AssumeRole"
  }]
}
EOF

# Create the role - no permissions attached yet
aws iam create-role \
  --role-name gfn-reports-role \
  --assume-role-policy-document file:///tmp/compass-trust.json \
  --description "Execution role for the gfn-reports service (Project Compass)" \
  --tags Key=Project,Value=Compass Key=ManagedBy,Value=learn-aws \
  --profile compass

# Attach AWS-managed basic Lambda logging policy
# (chapter 9 will swap this for a tighter custom one)
aws iam attach-role-policy \
  --role-name gfn-reports-role \
  --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole \
  --profile compass

# Verify
aws iam get-role --role-name gfn-reports-role --profile compass
aws iam list-attached-role-policies --role-name gfn-reports-role --profile compass

Recap & next

What stuck?

• Users vs Roles: users carry credentials; roles are assumed. Use Identity Center for humans and roles for workloads.
• Two policy directions: identity-based (attached to who's asking) and resource-based (attached to what's being touched). Either is enough for same-account; cross-account needs both.
• Trust policies are resource-based policies attached to roles. They list who can call sts:AssumeRole.
• Evaluation order: explicit Deny > SCPs > Allow checks. Default is Deny.
• Permission boundaries cap maximum permissions. They don't grant; they restrict.
• IRSA is the EKS workload-identity pattern: pod's projected JWT → STS → assume IAM role → temp creds.

The mental model in one sentence

Common pitfalls so far