Cloud IAM, Roles, and Policies

IAM Policy Structure and Least-Privilege Design

IAM is the control plane for every action taken in a cloud account. Every API call — reading a bucket, launching an instance, modifying a database — is an IAM authorization decision. If IAM is misconfigured, every other security control becomes irrelevant because the attacker can simply use legitimate credentials with excessive permissions.

The anatomy of an IAM policy

An IAM policy is a JSON document with a specific structure. Understanding this structure is the foundation of everything else in IAM:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowReadSpecificBucket",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::my-app-data",
        "arn:aws:s3:::my-app-data/*"
      ],
      "Condition": {
        "IpAddress": {"aws:SourceIp": "203.0.113.0/24"}
      }
    }
  ]
}

The key fields:

• Effect: Allow or Deny. An explicit Deny always overrides any Allow — this is the most important rule in IAM.
• Action: The specific API operations being permitted. Use wildcards (s3:*) sparingly — they're the most common source of over-permission.
• Resource: The specific ARNs the policy applies to. * means all resources — another common source of excessive privilege.
• Condition: Additional constraints (IP address, MFA presence, time of day, etc.) that must be met for the policy to apply.

The principle of least privilege

Least privilege means granting only the permissions required to perform a specific task — nothing more. In practice, this means:

1. Start with no permissions and add only what's needed
2. Scope to specific resources, not *
3. Use specific actions, not wildcard actions
4. Add conditions to constrain when and where the permission applies

// BAD: Over-permissive
{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

// GOOD: Least privilege
{
  "Effect": "Allow",
  "Action": ["s3:GetObject"],
  "Resource": "arn:aws:s3:::my-app-data/uploads/*",
  "Condition": {
    "Bool": {"aws:MultiFactorAuthPresent": "true"}
  }
}

Policy evaluation logic

When a principal attempts an action, the cloud provider evaluates all applicable policies in a specific order:

1. Explicit deny — if any policy explicitly denies the action, the request is denied immediately
2. Allow — if any policy allows the action (and no deny exists), the request is allowed
3. Default deny — if no policy explicitly allows the action, it's denied by default

This means IAM is deny-by-default: you must explicitly grant every permission. The danger is granting too much, not too little.

Identity-based vs. resource-based policies

There are two ways to attach permissions:

• Identity-based policies are attached to IAM users, groups, or roles. They define what that identity can do.
• Resource-based policies are attached to the resource itself (e.g., an S3 bucket policy). They define who can access that resource and what they can do.

When both exist, the evaluation is: (identity-based allow OR resource-based allow) AND NOT (explicit deny in either).

Roles and Temporary Credentials

Long-lived access keys are the most commonly leaked credential in cloud environments. They get committed to GitHub, stored in environment variables, logged in debug output, and embedded in CI/CD configurations. Once leaked, they provide persistent access until manually rotated — which often never happens.

Roles solve this problem by providing temporary, automatically-rotating credentials that expire after a short duration.

How roles work

A role is an identity with no long-lived credentials. Instead, you assume the role to receive temporary credentials:

# Assuming a role and receiving temporary credentials
aws sts assume-role \
  --role-arn arn:aws:iam::123456789012:role/AppReadOnly \
  --role-session-name my-session

# Response contains temporary credentials
{
  "Credentials": {
    "AccessKeyId": "ASIA...",
    "SecretAccessKey": "...",
    "SessionToken": "...",
    "Expiration": "2026-09-30T18:00:00Z"
  }
}

The temporary credentials:

• Expire after a configurable duration (15 minutes to 12 hours, default 1 hour)
• Are automatically rotated by the cloud provider
• Cannot be leaked in a way that provides persistent access
• Are tied to the session that requested them

Common role patterns

1. Service roles for compute:

Instead of putting access keys on an EC2 instance, attach an IAM role. The instance metadata service provides temporary credentials automatically:

# On an EC2 instance with an attached role — no keys needed
aws s3 ls s3://my-app-data/

# The instance automatically retrieves temporary credentials from
# http://169.254.169.254/latest/meta-data/iam/security-credentials/

2. Cross-account access:

Roles enable secure cross-account access without sharing credentials:

// Trust policy on the role in Account B
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"AWS": "arn:aws:iam::111111111111:root"},
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": {"sts:ExternalId": "unique-external-id-123"}
    }
  }]
}

The ExternalId condition prevents the confused deputy problem — it ensures that Account B can only be assumed by someone who knows the external ID.

3. CI/CD pipeline roles:

Build systems assume roles to deploy, rather than using stored access keys:

# GitHub Actions example
- name: Configure AWS credentials
  uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsDeploy
    aws-region: us-east-1

Permission boundaries

A permission boundary is an advanced feature that sets the maximum permissions an identity-based policy can grant. Even if a policy allows s3:*, a permission boundary that only allows s3:GetObject will cap the effective permissions:

// Permission boundary policy
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:ListBucket"],
    "Resource": "*"
  }]
}

Permission boundaries are useful for delegating policy creation — you can let team members create IAM policies, but the boundary ensures they can't grant more privilege than intended.

Service control policies (SCPs)

In AWS Organizations, SCPs act as permission boundaries at the organization level. They define what actions are allowed across all accounts in the organization:

// SCP that denies all actions outside us-east-1
{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyOutsideUSEast1",
    "Effect": "Deny",
    "NotAction": ["iam:*", "organizations:*", "route53:*"],
    "Resource": "*",
    "Condition": {
      "StringNotEquals": {"aws:RequestedRegion": "us-east-1"}
    }
  }]
}

SCPs are the most powerful guardrail in AWS — they can deny actions even if an account's IAM policies allow them.