implementing-aws-iam-permission-boundaries skill (Anthropic-Cybersecurity-Skills)

From Public Agent Wiki

What it does. Configures AWS IAM permission boundaries that cap the maximum permissions Part of mukul975/Anthropic-Cybersecurity-Skills (817 security skills) (mukul975/Anthropic-Cybersecurity-Skills).

Upstream mukul975/Anthropic-Cybersecurity-Skills
Skill file skills/implementing-aws-iam-permission-boundaries/SKILL.md
License Apache-2.0 (skill folder LICENSE)
Author mukul975
Fetched 2026-09-10

Install

  • npx skills add mukul975/Anthropic-Cybersecurity-Skills --skill implementing-aws-iam-permission-boundaries, or copy the skill folder into ~/.claude/skills/implementing-aws-iam-permission-boundaries/.
  • Raw file: curl -sL https://raw.githubusercontent.com/mukul975/Anthropic-Cybersecurity-Skills/HEAD/skills/implementing-aws-iam-permission-boundaries/SKILL.md

SKILL.md (verbatim)

name: implementing-aws-iam-permission-boundaries
description: Configures AWS IAM permission boundaries that cap the maximum permissions
  an identity-based policy can grant to a user or role, so effective permissions
  are the intersection of the identity policy and the boundary even if the policy
  grants AdministratorAccess. Use when letting security teams delegate IAM role and
  policy creation to developers for self-service while enforcing least-privilege
  ceilings and preventing privilege escalation.
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
mitre_attack:
- T1078
- T1110
- T1556
- T1098
- T1078.004

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:

{
    "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

References

Other files in this skill

assets/template.md (verbatim)

AWS IAM Permission Boundary Implementation Template

Boundary Policy Details

Field Value
Policy Name
AWS Account ID
Target Roles (prefix pattern, e.g., app-*)
Allowed Services
Created By
Date

Allowed Service Actions

Service Actions Allowed Justification
S3 s3:* Application data storage
DynamoDB dynamodb:* Application database
Lambda lambda:* Serverless compute
CloudWatch cloudwatch:, logs: Monitoring and logging

Denied Actions (Escalation Prevention)

Action Reason
iam:DeleteRolePermissionsBoundary Prevent boundary removal
iam:DeleteUserPermissionsBoundary Prevent boundary removal
iam:CreatePolicyVersion (on boundary) Prevent boundary modification
iam:SetDefaultPolicyVersion (on boundary) Prevent boundary modification

Testing Results

Test Case Expected Result Actual Result Pass/Fail
Create role with boundary Success
Create role without boundary AccessDenied
Use allowed service (e.g., S3) Success
Use blocked service (e.g., IAM admin) AccessDenied
Remove own boundary AccessDenied
Modify boundary policy AccessDenied

Sign-Off

Role Name Date
Security Engineer
Cloud Architect
DevOps Lead

references/api-reference.md (verbatim)

API Reference: AWS IAM Permission Boundary Agent

Dependencies

Library Version Purpose
boto3 >=1.28 AWS SDK for IAM permission boundary management

CLI Usage

python scripts/agent.py \
  --profile security-admin \
  --region us-east-1 \
  --audit \
  --output-dir /reports/ \
  --output iam_boundary_report.json

Functions

get_iam_client(profile, region)

Creates boto3 IAM client with optional named profile.

create_permission_boundary(client, policy_name, allowed_services, allowed_regions) -> dict

Creates an IAM policy for use as a permission boundary. Includes a DenyBoundaryChanges statement to prevent boundary removal. Uses client.create_policy().

attach_boundary_to_role(client, role_name, boundary_arn) -> dict

Calls client.put_role_permissions_boundary() to attach a boundary to a role.

audit_roles_without_boundary(client) -> list

Paginates client.list_roles() and identifies roles missing PermissionsBoundary.

audit_boundary_effectiveness(client, role_name) -> dict

Calls client.get_role(), list_attached_role_policies(), list_role_policies() to show effective policy stack.

generate_report(client) -> dict

Orchestrates audit and generates compliance report.

boto3 IAM Methods Used

Method Purpose
create_policy(PolicyName, PolicyDocument) Create boundary policy
put_role_permissions_boundary(RoleName, PermissionsBoundary) Attach boundary
list_roles() Enumerate all roles
get_role(RoleName) Get role details including boundary

Output Schema

{
  "roles_without_boundary_count": 12,
  "roles_without_boundary": [{"role_name": "dev-role", "arn": "arn:aws:iam::..."}],
  "recommendations": ["Attach permission boundaries to 12 roles"]
}

references/standards.md (verbatim)

AWS IAM Permission Boundaries - Standards Reference

AWS IAM Policy Types

Policy Type Scope Purpose
Identity-Based Attached to users/roles/groups Grants permissions
Resource-Based Attached to resources (S3, KMS) Cross-account access
Permission Boundary Attached to users/roles Maximum permission limit
Organizations SCP Attached to OUs/accounts Organization-wide limit
Session Policy Passed during AssumeRole Session-level limit

AWS Well-Architected Framework - Security Pillar

SEC02 - Identity Management

  • SEC02-BP02: Use temporary credentials (permission boundaries enforce this)
  • SEC02-BP05: Audit and rotate credentials regularly
  • SEC02-BP06: Employ user groups and attributes for fine-grained access

SEC03 - Permissions Management

  • SEC03-BP01: Define access requirements (boundary defines maximum)
  • SEC03-BP02: Grant least privilege access
  • SEC03-BP06: Manage access based on lifecycle
  • SEC03-BP07: Analyze public and cross-account access

CIS AWS Foundations Benchmark v3.0

  • 1.4: Ensure no root account access key exists
  • 1.15: Ensure IAM users receive permissions only through groups
  • 1.16: Ensure IAM policies that allow full admin privileges are not attached
  • 1.17: Ensure a support role has been created for incident management
  • 1.22: Ensure IAM policies with admin access are reviewed regularly

NIST SP 800-53 Mapping

  • AC-2: Account Management (boundary controls role creation)
  • AC-3: Access Enforcement (intersection of policies)
  • AC-5: Separation of Duties (boundary prevents security role access)
  • AC-6: Least Privilege (boundary enforces maximum permissions)
  • AC-6(1): Authorize Access to Security Functions
  • AC-6(5): Privileged Accounts (boundary limits even admin roles)

references/workflows.md (verbatim)

AWS IAM Permission Boundaries - Workflows

Boundary Policy Creation Workflow

1. Security team identifies allowed services for developer workloads
       │
2. Draft permission boundary policy (JSON)
       │
3. Peer review by second security engineer
       │
4. Test in sandbox account:
       ├── Create test role with boundary
       ├── Verify allowed actions succeed
       ├── Verify blocked actions are denied
       └── Verify boundary cannot be self-modified
       │
5. Commit policy to version control (IaC repository)
       │
6. Deploy via CI/CD pipeline (Terraform/CloudFormation)
       │
7. Attach boundary to all developer-created roles

Developer Role Creation Workflow (with Boundary)

Developer wants to create a new IAM role
       │
├── Developer writes role policy (only app-* prefixed)
│
├── Developer creates role with --permissions-boundary flag
│       │
│       └── If boundary not attached → API returns AccessDenied
│
├── AWS IAM validates:
│   ├── Role name matches required prefix (app-*)
│   ├── Permission boundary ARN matches required boundary
│   └── Developer has iam:CreateRole with boundary condition
│
├── Role created successfully with boundary attached
│
└── Effective permissions = identity policy ∩ boundary policy

Privilege Escalation Prevention Workflow

Attacker attempts to escalate privileges:

Attempt 1: Create role without boundary
    → Denied by developer policy (condition requires boundary)

Attempt 2: Modify the boundary policy itself
    → Denied by boundary's own deny statements

Attempt 3: Remove boundary from existing role
    → Denied by boundary deny on DeleteRolePermissionsBoundary

Attempt 4: Create policy granting iam:* access
    → Policy can only grant actions within boundary intersection

Attempt 5: Assume a role without boundary
    → Developer can only create roles with boundary condition

All escalation paths blocked ✓

Boundary Audit Workflow

Monthly audit:
    │
    ├── List all IAM roles in account
    │
    ├── Check each role for boundary attachment:
    │   ├── Has boundary → Verify correct boundary ARN
    │   └── No boundary → Flag for remediation
    │
    ├── Review boundary policy changes (CloudTrail)
    │
    ├── Check for new IAM actions added to AWS services
    │   └── Update boundary if new actions should be restricted
    │
    └── Generate compliance report

Back to mukul975/Anthropic-Cybersecurity-Skills (817 security skills) or Agent skills.