Aws Iam

---
name: aws-iam
description: "Expert agent for AWS IAM and IAM Identity Center. Provides deep expertise in IAM policies, roles, permission sets, SCPs, cross-account access, IAM Access Analyzer, ABAC with tags, and credential management. WHEN: \"AWS IAM\", \"IAM policy\", \"IAM role\", \"IAM Identity Center\", \"AWS SSO\", \"SCP\", \"permission set\", \"cross-account\", \"IAM Access Analyzer\", \"assume role\", \"trust policy\"."
license: MIT
---

# AWS IAM

This skill covers AWS Identity and Access Management (IAM) and IAM Identity Center (formerly AWS SSO). It has deep knowledge of IAM policies, roles, permission sets, Service Control Policies, cross-account access patterns, IAM Access Analyzer, ABAC with tags, and credential management.

## Identity and Scope

AWS IAM provides:
- **IAM users, groups, and roles** -- Identity management within AWS accounts
- **IAM policies** -- JSON-based policy language for fine-grained access control
- **IAM Identity Center** -- Centralized SSO and multi-account access management (formerly AWS SSO)
- **Service Control Policies (SCPs)** -- Guardrails for AWS Organizations member accounts
- **IAM Access Analyzer** -- Find unintended access to resources
- **ABAC with tags** -- Attribute-based access control using resource and principal tags
- **Credential management** -- Access keys, temporary credentials (STS), credential rotation

## How to Approach Tasks

When you receive a request:

1. **Classify** the request:
   - **Policy authoring** -- IAM policy language, conditions, resource-based policies
   - **Architecture** -- Cross-account access, multi-account strategy, permission boundaries
   - **Identity Center** -- SSO, permission sets, account assignments
   - **Governance** -- SCPs, access analysis, credential management
   - **Security** -- Least privilege, access review, incident response for IAM

2. **Identify scope** -- Single account, multi-account (Organizations), or cross-organization

3. **Analyze** -- Apply AWS IAM-specific reasoning. Consider policy evaluation logic, service-specific authorization, and the interaction between identity-based and resource-based policies.

4. **Recommend** -- Provide actionable guidance with policy JSON, CLI commands, and CloudFormation/Terraform examples.

## Core Expertise

### IAM Policy Language

AWS policies are JSON documents with the following structure:

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowS3ReadAccess",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-bucket",
        "arn:aws:s3:::my-bucket/*"
      ],
      "Condition": {
        "StringEquals": {
          "s3:prefix": ["home/${aws:username}/"]
        }
      }
    }
  ]
}
```

**Policy types:**

| Policy Type | Attached To | Purpose |
|---|---|---|
| **Identity-based** | Users, groups, roles | Grant permissions to the principal |
| **Resource-based** | Resources (S3, SQS, KMS, etc.) | Grant cross-account access to the resource |
| **Permission boundary** | Users, roles | Maximum permissions an entity CAN have (ceiling) |
| **SCP** | OUs, accounts (Organizations) | Maximum permissions accounts CAN have |
| **Session policy** | STS session | Limit permissions for a specific session |
| **VPC Endpoint policy** | VPC endpoints | Control which principals can use the endpoint |

### Policy Evaluation Logic

```
1. Start with DENY (default)
2. Evaluate all applicable policies:
   a. SCPs (if in AWS Organizations) -- Must ALLOW
   b. Resource-based policies -- Can ALLOW cross-account
   c. Identity-based policies -- Must ALLOW
   d. Permission boundaries -- Must ALLOW
   e. Session policies -- Must ALLOW
3. Explicit DENY in ANY policy = DENIED (overrides everything)
4. If no explicit DENY and all applicable policy types ALLOW = ALLOWED
```

**Key nuance:** For cross-account access, both the source account (identity-based) AND the target account (resource-based) must allow the action. Exception: resource-based policies that specify the principal's ARN (not `*`) can grant cross-account access without the source account's identity policy.

### IAM Roles and Trust Policies

Trust policies define WHO can assume a role:

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "unique-external-id"
        }
      }
    }
  ]
}
```

**Common trust patterns:**

| Pattern | Principal | Use Case |
|---|---|---|
| Cross-account | `arn:aws:iam::ACCOUNT:root` or specific role/user | Access resources in another account |
| AWS service | `Service: "ec2.amazonaws.com"` | EC2 instance profile, Lambda execution role |
| OIDC federation | `Federated: "arn:aws:iam::ACCOUNT:oidc-provider/..."` | GitHub Actions, Kubernetes IRSA |
| SAML federation | `Federated: "arn:aws:iam::ACCOUNT:saml-provider/..."` | Enterprise SSO via SAML |
| Self-assume | Same role ARN | Role chaining, session policy application |

### IAM Identity Center

Centralized SSO for multi-account AWS environments:

**Components:**
- **Identity source** -- Where users live (Identity Center directory, Active Directory, external IdP)
- **Permission sets** -- Templates that define AWS permissions (mapped to IAM roles in target accounts)
- **Account assignments** -- Map users/groups to permission sets in specific accounts

```bash
# Create a permission set
aws sso-admin create-permission-set \
  --instance-arn arn:aws:sso:::instance/ssoins-xxx \
  --name "ReadOnlyAccess" \
  --session-duration "PT8H"

# Attach managed policy to permission set
aws sso-admin attach-managed-policy-to-permission-set \
  --instance-arn arn:aws:sso:::instance/ssoins-xxx \
  --permission-set-arn arn:aws:sso:::permissionSet/ssoins-xxx/ps-xxx \
  --managed-policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess

# Assign permission set to a group in an account
aws sso-admin create-account-assignment \
  --instance-arn arn:aws:sso:::instance/ssoins-xxx \
  --permission-set-arn arn:aws:sso:::permissionSet/ssoins-xxx/ps-xxx \
  --principal-type GROUP \
  --principal-id "group-id" \
  --target-type AWS_ACCOUNT \
  --target-id "123456789012"
```

### Service Control Policies (SCPs)

SCPs are guardrails for AWS Organizations member accounts:

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyRegionsOutsideUSEU",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["us-east-1", "us-west-2", "eu-west-1"]
        },
        "ArnNotLike": {
          "aws:PrincipalARN": "arn:aws:iam::*:role/OrganizationAdmin"
        }
      }
    },
    {
      "Sid": "DenyLeavingOrganization",
      "Effect": "Deny",
      "Action": "organizations:LeaveOrganization",
      "Resource": "*"
    }
  ]
}
```

**SCP best practices:**
- SCPs do NOT grant permissions -- they only restrict
- Attach deny-list SCPs (allow `*`, deny specific actions)
- Always exclude a break-glass role from SCPs
- Test SCPs in a sandbox OU before applying broadly
- Common SCPs: deny region usage, deny root account usage, deny leaving org, deny disabling security services

### ABAC with Tags

Attribute-based access control using AWS tags:

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["ec2:StartInstances", "ec2:StopInstances"],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "ec2:ResourceTag/Project": "${aws:PrincipalTag/Project}"
        }
      }
    }
  ]
}
```

**ABAC advantages:**
- Scale permissions without creating new policies for each resource
- Self-managing: new resources with correct tags automatically covered
- Fewer policies to manage (one policy covers many resources)

**Tag strategy:**
- Require tags on resource creation (SCP or IAM policy)
- Standard tag keys: `Project`, `Environment`, `Owner`, `CostCenter`
- Tag principals (IAM users/roles) and resources consistently

### IAM Access Analyzer

Find unintended access to resources:

**Analyzer types:**
- **External access** -- Find resources shared with principals outside your account/organization
- **Unused access** -- Find unused roles, access keys, and permissions
- **Custom policy checks** -- Validate policies against security standards

```bash
# Create an analyzer
aws accessanalyzer create-analyzer --analyzer-name org-analyzer --type ORGANIZATION

# List findings
aws accessanalyzer list-findings --analyzer-arn arn:aws:access-analyzer:us-east-1:123456789012:analyzer/org-analyzer

# Validate a policy
aws accessanalyzer validate-policy --policy-type IDENTITY_POLICY --policy-document file://policy.json
```

### Credential Management Best Practices

| Credential Type | Use Case | Rotation | Security |
|---|---|---|---|
| **Root account** | Account setup only (then lock away) | Never (disable access keys) | MFA (hardware key), no access keys |
| **IAM user access keys** | Legacy programmatic access | 90 days max | Prefer roles + temporary credentials |
| **STS temporary credentials** | AssumeRole, federation | Auto-expire (1-12 hours) | Preferred for all programmatic access |
| **IAM Identity Center** | Human console/CLI access | Session-based | Central management, MFA enforced |
| **Service-linked roles** | AWS service access | N/A (managed by AWS) | Cannot modify, auto-created |

## Common Pitfalls

1. **Using root account for operations** -- Root account should only be used for initial setup and break-glass. Enable MFA with hardware key, delete access keys.
2. **Long-lived access keys** -- IAM user access keys are the most common credential leak vector. Use IAM roles with temporary credentials everywhere possible.
3. **Overly permissive policies** -- `"Action": "*", "Resource": "*"` is almost never appropriate. Use IAM Access Analyzer to right-size permissions.
4. **Missing permission boundaries** -- Without permission boundaries, a developer role that can create IAM roles can escalate to full admin by creating a role with `AdministratorAccess`.
5. **SCPs not tested** -- Deploying untested SCPs to production OUs can break automation and services. Test in sandbox OU first.
6. **Confused deputy** -- When allowing cross-account role assumption, always use `ExternalId` condition to prevent confused deputy attacks.
7. **Not using IAM Identity Center** -- Managing IAM users in each account is unscalable. Use Identity Center for centralized access management.