Amazon IAM

1. What is IAM?

AWS Identity and Access Management (IAM) controls who can call AWS and what they are allowed to do. It is global (not per-region) and free to use.

2. How access works (the big picture)

Principal (user / role / service)
        |
        v
Policies attached to the principal  ----+
        |                               |
        v                               v
Service control policies (org)    Resource-based policies
        |                               |
        +---------------+---------------+
                        v
              Evaluation: Deny wins,
              else Allow needed
                        |
                        v
              AWS API call succeeds / fails

Most permissions are identity-based. Resource policies are common for S3 bucket policies, Lambda function policies, KMS key policies, and cross-account access.

3. IAM entities: users, groups, roles

Root user vs IAM user

Access methods compared

4. Policy types

Effective permissions =
    Identity policy  ∩  Permissions boundary  ∩  SCP  ∩  (resource policy allow)
    ...unless an explicit Deny applies anywhere → Deny.

5. Anatomy of a policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowReadFromOneBucket",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::example-bucket",
        "arn:aws:s3:::example-bucket/*"
      ],
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": "us-east-1"
        }
      }
    }
  ]
}

Action wildcards

s3:*            all S3 actions          (too broad for production)
s3:Get*         all actions starting with Get
s3:GetObject    one precise action      (prefer this)

Conditions you will actually use

6. Policy evaluation logic

1. Start: request is denied by default (implicit deny).
2. Any explicit Deny anywhere (identity, resource, SCP, boundary)
   matching the request?  ---- YES ----> DENIED (final).
3. Any explicit Allow matching?  ------- NO ----> still denied (implicit deny).
4. Also check permissions boundaries and SCPs:
   the action must be allowed by identity policy
   AND not blocked by boundary/SCP.
5. ALLOW.

Example — force MFA for dangerous actions:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnlessMFA",
      "Effect": "Deny",
      "Action": [
        "iam:Delete*",
        "iam:Create*",
        "iam:Attach*",
        "iam:Detach*"
      ],
      "Resource": "*",
      "Condition": {
        "BoolIfExists": {
          "aws:MultiFactorAuthPresent": "false"
        }
      }
    }
  ]
}

7. IAM roles in depth

A role is the most important IAM concept in practice. It has two policies:

Caller ---- assume-role (STS) ----> Role
                                      |
                                      +--> Trust policy: is caller allowed in?
                                      +--> Permissions: what actions result?
                                      |
                                      v
                            Temporary credentials
                            (AccessKey, SecretKey, SessionToken)
                            expire (15 min – 12 hours)

Common role use cases

Example: EC2 instance role trust policy

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

Example: minimal S3-read permissions policy

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

Credentials on EC2 (instance metadata)

Applications on EC2 retrieve temporary credentials from instance metadata. Never bake access keys into AMIs or user data.

EC2 instance
    |
    v
Instance profile -> IAM role -> least-privilege policies -> AWS services

Require IMDSv2 (session tokens; blocks simple SSRF credential theft):

aws ec2 modify-instance-metadata-options \
  --instance-id i-0123456789abcdef0 \
  --http-tokens required \
  --http-endpoint enabled

Cross-account access (pattern)

Account A (trusted)                    Account B (owns the role)
Role: DataReader  <--- trust ---       Trust policy: allow Account A
Permissions: read S3 in Account B

1. In Account B, create role DataReader with a trust policy allowing Account A.
2. In Account A, the caller runs sts:AssumeRole on arn:aws:iam::B:role/DataReader.
3. Temporary credentials for the role are used for subsequent calls.

8. Federation and IAM Identity Center

Federation = use an external identity (company IdP, Active Directory, Google, etc.) to get AWS access without long-lived IAM users.

Human -> IdP (Okta/AD/Google)
            |
            v
    IAM Identity Center
            |
            v
    Permission set (policy) assumed into Target AWS account

Permission sets are templates (e.g. AdministratorAccess, PowerUser, ReadOnly) applied to users/groups per account.

9. MFA and access security

Setting a strong password policy (CLI sketch)

aws iam update-account-password-policy \
  --minimum-length 14 \
  --require-symbols \
  --require-numbers \
  --require-uppercase-characters \
  --require-lowercase-characters \
  --max-password-age 90 \
  --password-reuse-prevention 24

Access keys hygiene

aws iam list-access-keys --user-name my-user
aws iam get-access-key-last-used --access-key-id AKIA...

10. Tools: CLI, simulator, Access Analyzer

Useful IAM CLI commands

# Who am I?
aws sts get-caller-identity

# List users, groups, roles, policies
aws iam list-users
aws iam list-groups-for-user --user-name alice
aws iam list-attached-role-policies --role-name app-role
aws iam list-policies --scope Local

# Inline policies
aws iam list-role-policies --role-name app-role
aws iam get-role-policy --role-name app-role --policy-name my-inline

# Attach / detach managed policy
aws iam attach-role-policy \
  --role-name app-role \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess
aws iam detach-role-policy \
  --role-name app-role \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

# Assume a role and use it
aws sts assume-role \
  --role-arn arn:aws:iam::123456789012:role/DataReader \
  --role-session-name my-session

IAM policy simulator

Web tool: IAM → Policy simulator (or aws iam simulate-principal-policy). Answers "would this identity be allowed to do X on resource Y?" without executing the action. Excellent for debugging before granting more permissions.

IAM Access Analyzer

• Finds external sharing (roles trust outside accounts, public S3 buckets, unrestricted KMS keys, etc.).
• Can generate policies from CloudTrail activity (only actions the workload actually used).
• Validates policies against IAM best practices and AWS service limits.

Enable it in every region you use. Treat findings as a to-do list: every external share should be intentional.

CloudTrail for auditing

Every IAM API call (CreateUser, AttachRolePolicy, AssumeRole, …) appears in CloudTrail. Alert on:

• Root account usage
• IAM policy/role/user changes
• Failed AccessDenied spikes (possible probing)
• New access keys created

11. Troubleshooting AccessDenied

Debugging order

aws sts get-caller-identity          # 1. Who am I?
aws iam simulate-principal-policy \  # 2. Would this identity pass?
  --policy-source-arn arn:aws:iam::123456789012:role/app-role \
  --action-names s3:GetObject \
  --resource-arns arn:aws:s3:::example-bucket/*

Then read the error code carefully: AccessDenied, AccessDeniedException, UnauthorizedOperation — each points at a different layer (identity policy vs resource policy vs service auth).

12. IAM best practices checklist

• Never use the root account for daily work; secure it with hardware MFA and no access keys.
• Enable MFA for root and every IAM user (prefer hardware/FIDO2 for root).
• Prefer IAM Identity Center + roles over long-lived IAM users with access keys.
• Grant least privilege: precise actions, precise resources; avoid *:* and Resource: *.
• Use customer managed policies (versioned, reusable) over inline and broad AWS managed policies.
• Use permissions boundaries for roles that developers create.
• Use SCPs in AWS Organizations as org guardrails.
• EC2/Lambda/ECS always use roles, never embedded keys.
• Require IMDSv2 on all EC2 instances.
• Store secrets in Secrets Manager or Parameter Store (SecureString), not in code or user data.
• Rotate access keys automatically; delete unused keys and stale roles.
• Enable IAM Access Analyzer in all regions; act on findings.
• Enable CloudTrail and alarm on IAM changes and root usage.
• Review permissions quarterly; remove unused users, roles, and policies.
• Tag IAM entities (Team, Environment) for ownership and automation.