Implementing AWS Iam Permission Boundaries
Configure IAM permission boundaries in AWS to delegate role creation to developers while enforcing maximum privilege limits set by the security team.
MCP get_skill({ skillId: "implementing-aws-iam-permission-boundaries-5b7d1a05" })Use this skill with your agent
Create a free account and connect via MCP
# 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
### 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:
1. **Explicit Deny** in any policy - always wins
2. **Organizations SCP** - sets org-wide maximum
3. **Permission Boundary** - sets entity-level maximum
4. **Identity-Based Policy** - grants actual permissions
5. **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:
```json
{
"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:
```json
{
"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
```bash
# 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
```hcl
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
## References
- [AWS IAM Permission Boundaries Documentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)
- [When and Where to Use Permission Boundaries - AWS Security Blog](https://aws.amazon.com/blogs/security/when-and-where-to-use-iam-permissions-boundaries/)
- [AWS Example Permission Boundary - GitHub](https://github.com/aws-samples/example-permissions-boundary)
- [AWS Prescriptive Guidance - Creating Permission Boundaries](https://docs.aws.amazon.com/prescriptive-guidance/latest/transitioning-to-multiple-aws-accounts/creating-a-permissions-boundary.html)Related Skills
More skills in Security & Compliance
1password
Set up and use 1Password CLI (op). Use when installing the CLI, enabling desktop app integration, signing in, and reading/injecting secrets for commands.
1password
Set up and use 1Password CLI for sign-in, desktop integration, and reading or injecting secrets.
Accessibility Lead
Accessibility team lead and orchestrator. Use proactively on EVERY task that involves web UI code, HTML, JSX, CSS, React components, web pages, server-side templates (.leaf, .ejs, .erb, .hbs), or any user-facing web content. This agent coordinates the accessibility specialist team and ensures no accessibility requirement is missed. Runs the final review before any UI code is considered complete. Applies to any web framework, server-side templating framework (Vapor/Leaf, Rails/ERB, Django/Jinja, Express/EJS), or vanilla HTML/CSS/JS. Works alongside other team leads (e.g., swift-lead) in multi-language projects.
Accessibility Regression Detector
Detects accessibility regressions by comparing audit results across commits/branches. Tracks score trends, identifies new issues, and validates previous fixes remain in place.
Accessibility Statement
Generates conformance/accessibility statements following W3C or EU model templates. Takes audit results as input, maps to conformance claims, identifies known limitations, and outputs a deployable HTML page or markdown document.
Accessibility Tool Builder
Expert in building accessibility scanning tools, rule engines, document parsers, report generators, and audit automation. WCAG criterion mapping, severity scoring, CLI/GUI scanner architecture, CI/CD integration.
Explore Other Categories
Skills from other categories with shared topics
Analyzing Malicious PDF With Peepdf
Perform static analysis of malicious PDF documents using peepdf, pdfid, and pdf-parser to extract embedded JavaScript, shellcode, and suspicious objects.
Analyzing PDF Malware With Pdfid
Analyzes malicious PDF files using PDFiD, pdf-parser, and peepdf to identify embedded JavaScript, shellcode, exploits, and suspicious objects without opening the document. Determines the attack vector and extracts embedded payloads for further analysis. Activates for requests involving PDF malware analysis, malicious document analysis, PDF exploit investigation, or suspicious attachment triage.
Building Devsecops Pipeline With GitLab CI
Design and implement a comprehensive DevSecOps pipeline in GitLab CI/CD integrating SAST, DAST, container scanning, dependency scanning, and secret detection.