implementing-aws-iam-permission-boundaries

name: implementing-aws-iam-permission-boundaries description: Configure IAM permission boundaries in AWS to delegate role creation to developers while enforcing maximum privilege limits set by the security team. domain: cybersecurity subdomain: identity-access-management tags:

aws
iam
permission-boundaries
least-privilege
delegation
cloud-security version: '1.0' author: mahipal license: Apache-2.0 nist_csf:
PR.AA-01
PR.AA-02
PR.AA-05
PR.AA-06

Implementing AWS IAM Permission Boundaries

Overview

IAM permission boundaries are an advanced AWS feature that sets the maximum permissions an identity-based policy can grant to an IAM entity (user or role). They enable centralized security teams to safely delegate IAM role and policy creation to application developers without risking privilege escalation. The effective permissions of an entity are the intersection of its identity-based policies and its permission boundary -- even if an identity policy grants AdministratorAccess, the permission boundary restricts it to only the allowed actions.

When to Use

When deploying or configuring implementing aws iam permission boundaries capabilities in your environment
When establishing security controls aligned to compliance requirements
When building or improving security architecture for this domain
When conducting security assessments that require this implementation

Prerequisites

AWS account with IAM administrative access
Understanding of AWS IAM policy language (JSON)
AWS CLI v2 configured with appropriate credentials
Terraform or CloudFormation for infrastructure-as-code deployment

Core Concepts

This section covers core concepts for implementing aws iam permission boundaries.

Ensure all prerequisites are met before proceeding
Follow the documented workflow steps in sequence
Record results and any anomalies encountered during this phase

How Permission Boundaries Work

Identity-Based Policy          Permission Boundary
(What the role CAN do)    ∩    (What the role MAY do)
        │                              │
        └──────────┬───────────────────┘
                   │
          Effective Permissions
    (Only actions in BOTH policies)

Policy Evaluation Logic

AWS evaluates permissions in this order:

Explicit Deny in any policy - always wins
Organizations SCP - sets org-wide maximum
Permission Boundary - sets entity-level maximum
Identity-Based Policy - grants actual permissions
Resource-Based Policy - cross-account access (evaluated separately)

The entity can only perform an action if ALL applicable policy types allow it.

Key Use Cases

Use Case	Description
Developer Delegation	Allow devs to create IAM roles without escalating beyond their boundary
Sandbox Isolation	Limit what roles can do in sandbox/dev accounts
Multi-Tenant Workloads	Ensure tenant-specific roles cannot access other tenants' resources
CI/CD Pipeline Roles	Restrict automation roles to specific services

Workflow

Inventory cloud assets — enumerate services, roles, and configurations in scope
Assess configurations — check against security best practices and CIS benchmarks
Test access controls — verify IAM policies, network ACLs, and security group rules
Validate logging — ensure audit trails are enabled and properly retained
Document and remediate — report findings with specific configuration changes needed

Step 1: Define the Permission Boundary Policy

Create a managed policy that defines the maximum allowed permissions:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowedServices",
            "Effect": "Allow",
            "Action": [
                "s3:*",
                "dynamodb:*",
                "lambda:*",
                "logs:*",
                "cloudwatch:*",
                "sqs:*",
                "sns:*",
                "events:*",
                "states:*",
                "xray:*",
                "ec2:Describe*",
                "ec2:CreateTags",
                "sts:AssumeRole",
                "kms:Decrypt",
                "kms:GenerateDataKey",
                "kms:DescribeKey",
                "secretsmanager:GetSecretValue"
            ],
            "Resource": "*"
        },
        {
            "Sid": "AllowIAMPassRole",
            "Effect": "Allow",
            "Action": "iam:PassRole",
            "Resource": "arn:aws:iam::*:role/app-*",
            "Condition": {
                "StringEquals": {
                    "iam:PassedToService": [
                        "lambda.amazonaws.com",
                        "states.amazonaws.com"
                    ]
                }
            }
        },
        {
            "Sid": "DenyBoundaryDeletion",
            "Effect": "Deny",
            "Action": [
                "iam:DeletePolicy",
                "iam:DeletePolicyVersion",
                "iam:CreatePolicyVersion"
            ],
            "Resource": "arn:aws:iam::*:policy/DeveloperBoundary"
        },
        {
            "Sid": "DenyBoundaryRemoval",
            "Effect": "Deny",
            "Action": [
                "iam:DeleteUserPermissionsBoundary",
                "iam:DeleteRolePermissionsBoundary"
            ],
            "Resource": "*"
        }
    ]
}

Step 2: Create the Developer Delegation Policy

Grant developers the ability to create IAM roles, but only with the boundary attached:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowCreateRoleWithBoundary",
            "Effect": "Allow",
            "Action": [
                "iam:CreateRole",
                "iam:AttachRolePolicy",
                "iam:DetachRolePolicy",
                "iam:PutRolePolicy",
                "iam:DeleteRolePolicy"
            ],
            "Resource": "arn:aws:iam::*:role/app-*",
            "Condition": {
                "StringEquals": {
                    "iam:PermissionsBoundary": "arn:aws:iam::*:policy/DeveloperBoundary"
                }
            }
        },
        {
            "Sid": "AllowCreatePolicyScoped",
            "Effect": "Allow",
            "Action": [
                "iam:CreatePolicy",
                "iam:DeletePolicy",
                "iam:CreatePolicyVersion",
                "iam:DeletePolicyVersion"
            ],
            "Resource": "arn:aws:iam::*:policy/app-*"
        },
        {
            "Sid": "AllowViewIAM",
            "Effect": "Allow",
            "Action": [
                "iam:Get*",
                "iam:List*"
            ],
            "Resource": "*"
        }
    ]
}

Step 3: Attach the Boundary

# Create the boundary policy
aws iam create-policy \
    --policy-name DeveloperBoundary \
    --policy-document file://developer-boundary.json

# Attach boundary to an existing role
aws iam put-role-permissions-boundary \
    --role-name developer-role \
    --permissions-boundary arn:aws:iam::123456789012:policy/DeveloperBoundary

# Create a new role with boundary
aws iam create-role \
    --role-name app-lambda-executor \
    --assume-role-policy-document file://trust-policy.json \
    --permissions-boundary arn:aws:iam::123456789012:policy/DeveloperBoundary

Step 4: Prevent Privilege Escalation

The boundary must include deny statements to prevent developers from:

Removing the boundary from their own roles
Modifying the boundary policy itself
Creating roles without the boundary attached
Accessing IAM services to escalate privileges

Step 5: Deploy with Terraform

resource "aws_iam_policy" "developer_boundary" {
  name   = "DeveloperBoundary"
  path   = "/"
  policy = file("${path.module}/policies/developer-boundary.json")
}

resource "aws_iam_role" "app_role" {
  name                 = "app-lambda-executor"
  assume_role_policy   = data.aws_iam_policy_document.lambda_trust.json
  permissions_boundary = aws_iam_policy.developer_boundary.arn
}

Validation Checklist

Permission boundary policy created and reviewed by security team
Boundary includes deny statements preventing self-modification
Developer delegation policy requires boundary on all new roles
Role naming convention enforced (e.g., app-* prefix)
Developers tested creating roles with and without boundary (should fail without)
Privilege escalation paths tested and blocked
CloudTrail logging enabled for IAM API calls
Boundary policy versioned in source control
Automated tests validate boundary effectiveness
Documentation provided to development teams

When NOT to Use

You need to test the implementation (use performing-* skills)
Task is about configuring existing tools (use configuring-* skills)
You need to analyze security events (use analyzing-* skills)
Task is about building detection rules (use building-* skills)
You don't have access to the target environment
Task requires vendor-specific expertise (consult vendor docs)

Red Flags

Performing actions without explicit written authorization from the asset owner
Testing against production systems without a defined scope and rules of engagement
Modifying cloud IAM policies or security groups without approval
Exposing cloud credentials or secrets in logs or reports
Running scans that generate excessive API calls and trigger billing alerts

Verification

All steps executed successfully against a test environment before production use
Output documented with screenshots or logs demonstrating expected behavior
Cloud resource changes reverted or documented as intentional
IAM policies reviewed for least-privilege compliance after testing
No residual test resources left running (cost and security check)