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
Common Misconfigurations & Verification
- Boundary created but not attached: the maximum-permission policy exists but
iam:CreateRole delegation does not enforce iam:PermissionsBoundary, so developers mint roles with no boundary and full identity-policy power. Verify the delegation policy's Condition requires the exact boundary ARN and test aws iam create-role without --permissions-boundary — it must be denied.
- Privilege-escalation gaps in the boundary: if the boundary allows
iam:CreatePolicyVersion, iam:AttachRolePolicy on *, or iam:DeleteRolePermissionsBoundary, a delegated role can edit its own boundary or escape it. Confirm explicit Deny on boundary self-modification and on iam:PassRole to unscoped roles.
- Boundary ≠ Deny: a permission boundary only caps the maximum; it grants nothing and does not stop actions an attached identity policy already denies-by-omission, nor does it filter resource-based policy access. Remember effective access = identity policy ∩ boundary ∩ SCP, and explicit Deny anywhere wins.
- SCP/boundary confusion: SCPs bound the whole account/OU and do not grant; relying on a boundary where an SCP is needed (or vice-versa) leaves gaps. Verify both layers for cross-account
sts:AssumeRole.
- Verification: run
aws iam simulate-principal-policy against the boundaried role for a denied action (e.g. iam:DeleteRolePermissionsBoundary) and confirm denied; attempt to create a role without the boundary and an escalation via CreatePolicyVersion and confirm both fail in CloudTrail.
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
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
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",
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"
Step 3: Attach the Boundary
aws iam create-policy \
--policy-name DeveloperBoundary \
--policy-document file://developer-boundary.json
aws iam put-role-permissions-boundary \
--role-name developer-role \
--permissions-boundary arn:aws:iam::123456789012:policy/DeveloperBoundary
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
References
