14.2 IAM Permissions Boundaries & Delegated Administration

The Enterprise IAM Challenge: Bottlenecks vs. Privilege Escalation

In high-velocity cloud engineering environments, developers and automated CI/CD pipelines continuously provision compute infrastructure—such as AWS Lambda functions, Amazon ECS tasks, and AWS CodeBuild project environments. Each of these compute resources requires an execution role with tailored IAM permissions.

Traditionally, organizations face a painful architectural dilemma:

1. Centralized Security Bottleneck: The central security team manually reviews and provisions every IAM role and policy. This introduces severe development friction, stalls deployment velocity, and incentivizes engineers to seek insecure workarounds.
2. Unrestricted Developer Access: Developers are granted iam:CreateRole and iam:AttachRolePolicy to self-serve. Without guardrails, a developer can create a role with AdministratorAccess, attach it to an EC2 instance or Lambda function, and immediately escalate their privileges to full account takeover.

IAM Permissions Boundaries solve this dilemma by enabling Delegated IAM Administration. A permissions boundary establishes an immutable maximum entitlement ceiling (an authorization guardrail) that limits the effective permissions of an IAM user or role, regardless of what identity policies are attached.

---

Mechanics of IAM Permissions Boundaries

An IAM permissions boundary is an advanced feature that uses an existing customer-managed IAM policy to set the maximum permissions that an identity-based policy can grant to an IAM entity.

Critical Rules of Permissions Boundaries

• Ceiling, Not a Grant: A permissions boundary does not grant any permissions. It merely defines the boundary. An entity with a permissions boundary allowing AdministratorAccess (*:*) can perform zero actions until an identity-based policy is attached that explicitly grants permissions.
• Intersection Evaluation: The effective permissions of the entity are strictly the intersection of the identity-based policy and the permissions boundary (IdentityPolicy ∩ PermissionsBoundary).
• Target Entities: Permissions boundaries can be attached to IAM Users and IAM Roles. They cannot be attached to IAM Groups, and they do not apply to resource-based policies or the account root user.

┌────────────────────────────────────────────────────────┐
│            Customer-Managed Policy Definition          │
│         "arn:aws:iam::123456789012:policy/DevCeiling"  │
│  Allows: S3 (*), DynamoDB (*), CloudWatch Logs (*)     │
└───────────────────────────┬────────────────────────────┘
                            │ (Attached as Boundary)
                            ▼
               ┌─────────────────────────┐
               │    IAM Execution Role   │
               │  "PaymentProcessorRole" │
               └────────────┬────────────┘
                            │ (Attached as Identity Policy)
                            ▼
┌────────────────────────────────────────────────────────┐
│                 Attached Identity Policy               │
│  Allows: S3 (*), DynamoDB (*), Amazon SQS (*), IAM (*) │
└───────────────────────────┬────────────────────────────┘
                            │
                            ▼
┌────────────────────────────────────────────────────────┐
│                  EFFECTIVE PERMISSIONS                 │
│  Allows: S3 (*) and DynamoDB (*) ONLY                  │
│  (SQS and IAM are denied because they exceed boundary) │
└────────────────────────────────────────────────────────┘

---

Implementing Delegated Administration: The 3-Step Pattern

To securely delegate IAM role creation to developers, the central security team deploys a framework comprising three discrete elements:

Step 1: Define the Permissions Boundary Policy

The security team authors and locks down the boundary policy (arn:aws:iam::123456789012:policy/DevRoleBoundary). This policy defines the outer limit of what any developer-created role can do (e.g., allow S3, DynamoDB, SQS, SNS, and CloudWatch, but explicitly deny access to billing, production database secrets, or IAM manipulation).

Step 2: Grant Delegated Role Creation Conditioned on Boundary Attachment

The developers are granted iam:CreateRole, iam:AttachRolePolicy, and iam:PutRolePolicy. However, role creation is strictly conditioned on attaching the specified boundary policy using the iam:PermissionsBoundary condition key.

Step 3: Block All Privilege Escalation Pathways

The developers are explicitly denied from modifying or deleting the boundary, altering the boundary policy document, or passing arbitrary roles to compute services.

---

Production Delegated Administration Policy JSON

The following IAM policy demonstrates a production-grade delegated administration policy attached to a developer group or CI/CD automation role:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowRoleCreationWithMandatoryBoundary",
      "Effect": "Allow",
      "Action": [
        "iam:CreateRole",
        "iam:PutRolePermissionsBoundary"
      ],
      "Resource": "arn:aws:iam::123456789012:role/app-team/*",
      "Condition": {
        "StringEquals": {
          "iam:PermissionsBoundary": "arn:aws:iam::123456789012:policy/DevRoleBoundary"
        }
      }
    },
    {
      "Sid": "AllowPolicyManagementOnAppRoles",
      "Effect": "Allow",
      "Action": [
        "iam:AttachRolePolicy",
        "iam:DetachRolePolicy",
        "iam:PutRolePolicy",
        "iam:DeleteRolePolicy"
      ],
      "Resource": "arn:aws:iam::123456789012:role/app-team/*"
    },
    {
      "Sid": "PreventBoundaryRemovalOrTampering",
      "Effect": "Deny",
      "Action": [
        "iam:DeleteRolePermissionsBoundary",
        "iam:DeleteUserPermissionsBoundary"
      ],
      "Resource": "*"
    },
    {
      "Sid": "PreventBoundaryPolicyModification",
      "Effect": "Deny",
      "Action": [
        "iam:CreatePolicyVersion",
        "iam:DeletePolicyVersion",
        "iam:DeletePolicy",
        "iam:SetDefaultPolicyVersion"
      ],
      "Resource": "arn:aws:iam::123456789012:policy/DevRoleBoundary"
    },
    {
      "Sid": "RestrictedPassRoleToComputeServices",
      "Effect": "Allow",
      "Action": "iam:PassRole",
      "Resource": "arn:aws:iam::123456789012:role/app-team/*",
      "Condition": {
        "StringEquals": {
          "iam:PassedToService": [
            "lambda.amazonaws.com",
            "ecs-tasks.amazonaws.com"
          ]
        }
      }
    }
  ]
}

---

Privilege Escalation Attack Vectors & Hardened Countermeasures

When designing delegated administration policies, DevOps engineers must defend against five distinct privilege escalation vectors:

1. Removing the Permissions Boundary

• The Exploit: A developer creates a role with the boundary attached, and subsequently calls iam:DeleteRolePermissionsBoundary to remove the ceiling, leaving the role unbounded.
• Countermeasure: Explicitly deny iam:DeleteRolePermissionsBoundary on all resources.

2. Overwriting the Boundary with a Permissive Policy

• The Exploit: A developer invokes iam:PutRolePermissionsBoundary targeting the role, but points to a completely unrestricted policy (such as AdministratorAccess).
• Countermeasure: Enforce Condition: {"StringEquals": {"iam:PermissionsBoundary": "arn:aws:iam::123456789012:policy/DevRoleBoundary"}} on iam:PutRolePermissionsBoundary.

3. Modifying the Boundary Policy Document Itself

• The Exploit: A developer has permissions to manage IAM policies and calls iam:CreatePolicyVersion or iam:SetDefaultPolicyVersion against the boundary policy ARN, adding "Action": "*", "Effect": "Allow".
• Countermeasure: Explicitly deny iam:CreatePolicyVersion, iam:SetDefaultPolicyVersion, and iam:DeletePolicy targeting the boundary policy ARN.

4. Unrestricted iam:PassRole Exploitation

• The Exploit: An engineer cannot create administrative roles, but they discover an existing administrative role (e.g., EmergencyBreakGlassRole or CloudFormationDeploymentRole) in the account. If the engineer has iam:PassRole on Resource: *, they can configure an EC2 instance or Lambda function to execute under the administrative role and take over the account.
• Countermeasure: Restrict iam:PassRole strictly to role ARNs matching the delegated path (arn:aws:iam::123456789012:role/app-team/*) and enforce the iam:PassedToService condition key to restrict which AWS services can accept the role.

5. Creating Users Without Boundaries

• The Exploit: If developers have iam:CreateUser without a boundary condition, they can create an IAM user with access keys and assign it full administrative privileges.
• Countermeasure: If user creation is permitted, enforce StringEquals: {"iam:PermissionsBoundary": "..."} on iam:CreateUser, or completely deny iam:CreateUser and mandate IAM role usage exclusively.

---

Permissions Boundaries vs. Service Control Policies (SCPs)

Both Permissions Boundaries and SCPs act as guardrail mechanisms, but their administrative scope, operational ownership, and evaluation mechanisms are fundamentally distinct.