IAM (Identity Foundation)
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
000000000000in Floci/LocalStack-style emulators — don't chase a "real" account ID, it's a fixed placeholder. AWS_SESSION_TOKENmust be unset (or reset viaeval $(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?