IAM — Identity and Access Management

Every cloud call eventually passes through "who · what · where" questions. In AWS, the place that answers them is IAM (Identity and Access Management). Compared with the flashier managed services, IAM has a plain text-policy surface — yet a large share of operational incidents originate here.

1. About IAM

When	Event
2010	IAM general availability + MFA devices.
2012	IAM Roles.
2018	Permission Boundary.
2019	IAM Access Analyzer.
2022	IAM Identity Center (rebrand of the former SSO).

Operates globally across regions and is free (no resource charges).

Core objects:

• Root user — The top-level user created with the account. Not used for daily work.
• IAM User — A person or system identity.
• IAM Group — A bundle of users.
• IAM Role — An identity assumed by someone with temporary credentials.
• Policy — A bundle of permission rules written in JSON.

2. Policy structure

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:PutObject"],
    "Resource": "arn:aws:s3:::my-bucket/*",
    "Condition": {
      "StringEquals": { "s3:prefix": "uploads/" }
    }
  }]
}

Effect is Allow or Deny. Explicit Deny always wins. Action is the service prefix + operation name. Resource is an ARN. Condition adds constraints like IP, time, tags, MFA, and so on.

3. Managed vs Inline

Type	Notes
AWS Managed Policy	Standard policy authored by AWS. Example: AmazonS3ReadOnlyAccess.
Customer Managed Policy	Reusable policy authored by the user. Attach to multiple identities.
Inline Policy	A policy embedded directly in one identity. Deleted with the identity.

Customer Managed is recommended in production. Reuse, version control, and CloudFormation tracking come naturally.

4. Identity-based vs Resource-based

• Identity-based — Policy attaches to an IAM User · Group · Role. "What this identity can do."
• Resource-based — Policy attaches to a resource (S3 Bucket Policy · KMS Key Policy · Lambda Resource Policy). "Who can access this resource."

For a call to succeed, both policies must Allow it, or one Allow exists and the other is not an explicit Deny.

5. AssumeRole · STS

STS (Security Token Service) issues temporary credentials. The most common entry point is the AssumeRole API.

aws sts assume-role \
  --role-arn arn:aws:iam::123456789012:role/AppRole \
  --role-session-name app-session

The response returns AccessKeyId · SecretAccessKey · SessionToken · expiration. Default expiry is 1 hour (max 12). EC2 instance profiles, Lambda execution roles, and IRSA (EKS) all internally call AssumeRole to receive temporary credentials.

6. Trust Policy

A Role has two policies attached. Permission Policy (what this role can do) and Trust Policy (who can assume this role).

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

This Trust Policy says the EC2 service can assume the role. Putting another account's ARN as Principal allows cross-account access.

7. Permission Boundary

The upper bound of permissions an identity can be granted. Policies that exceed the boundary become null even when attached. Often used as a safety net for delegated permissions (allowing developers to create IAM objects for their own teams).

8. IAM Access Analyzer

Analyzes resource-based policies and reports surfaces exposed externally (other accounts or public). Targets include S3, KMS, Lambda, and IAM Role trust policies.

9. IAM Identity Center

Organization-wide SSO. Integrates with AD · Okta · Azure AD and issues short-lived console/CLI credentials. Organizations operating multiple AWS accounts are encouraged to use Identity Center Permission Sets rather than directly creating IAM Users.

10. Counterparts in other clouds

• Azure — RBAC + Managed Identity. Roles scoped to Subscription · Resource Group.
• GCP — Service Account is a first-class identity. Workload Identity Federation.
• Cloudflare Zero Trust · Tailscale ACL — Enforce identity at the network layer.
• Vault (HashiCorp) — Dynamic credential issuance. AWS · DB · SSH.

11. Least privilege + MFA

• Grant only the necessary Action; reserve * for emergencies and exceptions.
• Narrow resource ARNs as far as possible.
• Add IP, MFA, and Tag constraints via Condition.
• Verify policy changes with Access Analyzer · IAM Policy Simulator.

Enforcing MFA:

{
  "Effect": "Deny",
  "Action": "iam:DeleteUser",
  "Resource": "*",
  "Condition": {
    "BoolIfExists": { "aws:MultiFactorAuthPresent": "false" }
  }
}

Long-lived access keys (IAM Users) bring rotation and exposure risk. Where possible, replace with Roles + STS temporary credentials (EC2 instance profiles, Lambda execution roles, OIDC federation).

12. Common pitfalls

Lingering * policies — Started as Action: *, Resource: * for convenience and never tightened. Audit periodically.

Missing trust policy — Without the calling principal in a Role's Trust Policy, the assume itself fails. A frequent cause of "AccessDenied."

Conflict between resource-based and identity-based — When one Allows and the other Denies, Deny wins. Always inspect both.

Daily use of root credentials — Hard to recover from incidents. Use a separate IAM User or Identity Center, then lock the root.

Missing session token — When obtaining temporary credentials, set SessionToken in the environment in addition to AccessKey and SecretKey.

Confusing Permission Boundary with SCP — SCP (Service Control Policy) is at the Organization level; Permission Boundary is at IAM level. Both layers operate at once.

Closing thoughts

IAM has a plain surface, which makes incidents hard to spot. The three most common patterns are * permissions, daily use of root credentials, and unenforced MFA. Treat Access Analyzer and Policy Simulator as base tools in routine operations.

Next

• s3
• rds

IAM User Guide · STS · IAM Identity Center · Policy Simulator · Access Analyzer · Vault · GitHub Actions OIDC for reference.