02 — IAM & Security

IAM Overview

Identity and Access Management — controls WHO can do WHAT on which AWS resources.

IAM Entity          Example
─────────────────   ──────────────────────────
Root Account        Full access (never use for daily work)
IAM User            developer@company (long-term credentials)
IAM Group           "Developers", "Admins" (attach policies to groups)
IAM Role            EC2 instance role, Lambda role (temporary credentials)
IAM Policy          JSON document defining permissions

---

IAM Policies

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowS3Read",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-bucket",
        "arn:aws:s3:::my-bucket/*"
      ]
    },
    {
      "Sid": "DenyDeleteBucket",
      "Effect": "Deny",
      "Action": "s3:DeleteBucket",
      "Resource": "*"
    }
  ]
}

Policy Evaluation Logic

1. Explicit Deny?     → DENY (always wins)
2. Explicit Allow?    → ALLOW
3. Neither?           → DENY (default deny)

Policy Types

---

IAM Roles

Roles provide temporary credentials — no long-term keys.

Use roles for:
  EC2 instance   → Access S3, DynamoDB without hardcoded keys
  Lambda function → Access any AWS service
  ECS task        → Access resources
  Cross-account   → Account A assumes role in Account B

# Create role and attach policy
aws iam create-role --role-name LambdaS3Role \
  --assume-role-policy-document file://trust-policy.json

aws iam attach-role-policy --role-name LambdaS3Role \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

Trust Policy (who can assume the role)

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

---

Best Practices

✅ Enable MFA on root account and all IAM users
✅ Use IAM roles (not access keys) for AWS services
✅ Follow least privilege — grant minimum permissions needed
✅ Use groups to manage permissions (not individual users)
✅ Rotate access keys regularly
✅ Use AWS Organizations + SCPs for multi-account
✅ Enable CloudTrail to audit all API calls
✅ Never hardcode credentials in code — use roles or Secrets Manager

---

Security Services Overview

---

MFA & Access Keys

# List access keys
aws iam list-access-keys --user-name developer

# Rotate key
aws iam create-access-key --user-name developer
# Update ~/.aws/credentials with new key
aws iam delete-access-key --user-name developer --access-key-id AKIA_OLD

# Enable MFA (via console recommended)
# Or use CLI with virtual MFA device ARN

---

Cross-Account Access

Account A (dev) needs to access S3 in Account B (prod):

1. Account B creates role "CrossAccountS3" with trust for Account A
2. Account A user assumes the role:
   aws sts assume-role --role-arn arn:aws:iam::ACCOUNT_B:role/CrossAccountS3
3. Use temporary credentials returned

---

Key Takeaways

• Never use root account for daily work — create IAM users/roles
• Roles > Access Keys — temporary credentials are more secure
• Least privilege — start with zero permissions, add only what's needed
• Group policies — attach permissions to groups, add users to groups
• Explicit Deny always wins over Allow in policy evaluation
• Enable MFA, CloudTrail, and GuardDuty from day one