Chapter 1 — IAM (Identity Foundation)

Day 1 — Users, Roles, and Policy Syntax

1. Concept Primer

IAM has four building blocks: Users (long-lived identities), Groups (collections of users), Roles (assumable identities with no permanent credentials), and Policies (JSON documents describing allow/deny on actions + resources). Policy evaluation always resolves an explicit Deny over any Allow, and with no matching statement the default is implicit deny.

2. Hands-on Exercise

Create a role, attach an inline policy granting S3 read-only access, and read the policy back to understand the JSON shape.

3. Exact Commands

floci start && eval $(floci env)

# Trust policy: who is allowed to assume this role
cat > trust-policy.json << 'EOF'
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Service": "lambda.amazonaws.com" },
    "Action": "sts:AssumeRole"
  }]
}
EOF

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

# Permission policy: what the role can actually do
cat > s3-read-policy.json << 'EOF'
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:ListBucket"],
    "Resource": ["arn:aws:s3:::day1-bucket", "arn:aws:s3:::day1-bucket/*"]
  }]
}
EOF

aws iam put-role-policy \
  --role-name s3-read-role \
  --policy-name s3-read-inline \
  --policy-document file://s3-read-policy.json

aws iam get-role --role-name s3-read-role
aws iam get-role-policy --role-name s3-read-role --policy-name s3-read-inline

4. Gotchas

• Floci accepts and stores IAM calls faithfully (create/attach/get all work), but it does not enforce policy at the API layer the way real AWS's authorization engine does — a Lambda without the right permissions may still succeed locally. Treat this chapter as syntax and structure practice, and verify actual enforcement behavior against a real account (or a Floci changelog) before assuming parity.
• ARNs in policies still need to match the exact resource names you created, even locally.

5. Self-Check

What's the difference between the trust policy attached at role creation and the permission policy attached with put-role-policy — which one controls "who can become this role" vs "what this role can do"?

Day 2 — STS AssumeRole and Temporary Credentials

1. Concept Primer

STS (Security Token Service) issues short-lived credentials when a principal assumes a role. This is the mechanism behind cross-account access, federated identity, and how compute services (Lambda, ECS tasks) get scoped permissions without static keys.

2. Hands-on Exercise

Assume the role from Day 1, capture the temporary credentials, and use them directly (instead of your default test/test creds) to call S3.

3. Exact Commands

eval $(floci env)

CREDS=$(aws sts assume-role \
  --role-arn arn:aws:iam::000000000000:role/s3-read-role \
  --role-session-name day2-session)

echo "$CREDS" | python3 -m json.tool

# Extract and export the temporary credentials
export AWS_ACCESS_KEY_ID=$(echo "$CREDS" | python3 -c "import sys,json;print(json.load(sys.stdin)['Credentials']['AccessKeyId'])")
export AWS_SECRET_ACCESS_KEY=$(echo "$CREDS" | python3 -c "import sys,json;print(json.load(sys.stdin)['Credentials']['SecretAccessKey'])")
export AWS_SESSION_TOKEN=$(echo "$CREDS" | python3 -c "import sys,json;print(json.load(sys.stdin)['Credentials']['SessionToken'])")

# Now calls use the assumed-role identity
aws sts get-caller-identity
aws s3 ls s3://day1-bucket/

# Reset back to default test creds when done
eval $(floci env)

4. Gotchas

• The account ID in ARNs defaults to 000000000000 in Floci/LocalStack-style emulators — don't chase a "real" account ID, it's a fixed placeholder.
• AWS_SESSION_TOKEN must be unset (or reset via eval $(floci env)) when you want to go back to your base credentials, or every subsequent call will try to use the expired session token.

5. Self-Check

Why does aws sts get-caller-identity return a different ARN after you export the assumed role's temporary credentials, compared to before?