9.2 Permission Boundaries & Safe Admin Delegation

9.2 Permission Boundaries & Safe Admin Delegation

In modern cloud engineering, modernizing deployment velocity requires decentralizing administrative tasks. Continuous integration and continuous delivery (CI/CD) pipelines, serverless architectures, and containerized microservices frequently require creating new IAM roles for AWS Lambda functions, Amazon ECS tasks, and automated deployment jobs. However, granting engineers unrestricted iam:CreateRole and iam:AttachRolePolicy permissions introduces catastrophic privilege escalation risks.

An IAM Permission Boundary is an advanced authorization control that establishes the absolute maximum permissions an identity-based policy can grant to an IAM entity. By pairing permission boundaries with conditioned IAM policies, enterprise security teams achieve safe administrative delegation—allowing developers to provision and manage their own application roles without the ability to escalate privileges to full account administrator.

---

The Delegation Dilemma & Privilege Escalation Vectors

When security teams attempt to delegate role creation naively, they encounter a critical vulnerability: the Unbounded Role Creation Exploit.

Consider an IAM policy that allows a developer to perform iam:CreateRole and iam:AttachRolePolicy so they can configure IAM roles for their microservices. Without boundary guardrails, the developer can execute the following privilege escalation sequence:

Loading diagram...

1. The developer invokes iam:CreateRole to create an arbitrary role named BackdoorAdminRole with a trust policy allowing themselves to assume it.
2. The developer invokes iam:AttachRolePolicy, attaching the AWS-managed AdministratorAccess policy to BackdoorAdminRole.
3. The developer assumes BackdoorAdminRole using sts:AssumeRole.
4. The developer now possesses unrestricted *:* administrative permissions, bypassing all original organizational constraints, altering audit logs, or modifying production infrastructure.

To prevent this, security architects implement Permission Boundaries as non-bypassable guardrails.

---

Mechanics of IAM Permission Boundaries

A permission boundary is a standard customer-managed IAM policy that is applied to an IAM user or role to define its maximum allowable permissions. It does not grant permissions by itself; rather, it functions as an authorization filter.

Loading diagram...

Mathematical Intersection Model

The effective permissions of any principal subject to a permission boundary represent the strict intersection of the identity-based policy and the boundary:

Effective Permissions = Identity Policy ∩ Permission Boundary

• If an action is permitted by the identity policy but omitted from the boundary, the action is implicitly denied.
• If an action is permitted by the boundary but omitted from the identity policy, the action is implicitly denied.
• If an action is explicitly denied in either the identity policy or the boundary, the action is explicitly denied.
• Both policies must explicitly allow the action for access to be granted.

---

The Three-Tier Safe Delegation Architecture

Enterprise delegation relies on a synchronized three-tier policy framework comprising the Delegator Policy, the Permission Boundary Policy, and the Delegated Workload Policy:

Loading diagram...

1. The Delegator Policy (Attached to DevOps Engineers)

The Delegator Policy grants developers the ability to create roles, attach policies, and pass roles to compute services, but conditions those actions strictly on the presence of the boundary policy.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowRoleCreationWithBoundary",
      "Effect": "Allow",
      "Action": [
        "iam:CreateRole"
      ],
      "Resource": "arn:aws:iam::111122223333:role/app-roles/*",
      "Condition": {
        "StringEquals": {
          "iam:PermissionsBoundary": "arn:aws:iam::111122223333:policy/AppPermissionBoundary"
        }
      }
    },
    {
      "Sid": "AllowPolicyAttachmentToBoundedRoles",
      "Effect": "Allow",
      "Action": [
        "iam:AttachRolePolicy",
        "iam:PutRolePolicy",
        "iam:DetachRolePolicy",
        "iam:DeleteRolePolicy"
      ],
      "Resource": "arn:aws:iam::111122223333:role/app-roles/*",
      "Condition": {
        "StringEquals": {
          "iam:PermissionsBoundary": "arn:aws:iam::111122223333:policy/AppPermissionBoundary"
        }
      }
    },
    {
      "Sid": "PreventBoundaryTampering",
      "Effect": "Deny",
      "Action": [
        "iam:DeleteRolePermissionsBoundary",
        "iam:PutRolePermissionsBoundary",
        "iam:DeleteUserPermissionsBoundary",
        "iam:PutUserPermissionsBoundary"
      ],
      "Resource": "*"
    },
    {
      "Sid": "PreventBoundaryPolicyModification",
      "Effect": "Deny",
      "Action": [
        "iam:CreatePolicyVersion",
        "iam:DeletePolicyVersion",
        "iam:DeletePolicy",
        "iam:SetDefaultPolicyVersion"
      ],
      "Resource": "arn:aws:iam::111122223333:policy/AppPermissionBoundary"
    },
    {
      "Sid": "AllowPassRoleToApprovedServices",
      "Effect": "Allow",
      "Action": "iam:PassRole",
      "Resource": "arn:aws:iam::111122223333:role/app-roles/*",
      "Condition": {
        "StringEqualsIfExists": {
          "iam:PassedToService": [
            "lambda.amazonaws.com",
            "ecs-tasks.amazonaws.com"
          ]
        }
      }
    }
  ]
}

Critical Policy Statement Rationale

• Statement 1 (AllowRoleCreationWithBoundary): Allows iam:CreateRole strictly under the path /app-roles/* and enforces the iam:PermissionsBoundary condition key. If a developer attempts to run aws iam create-role without --permissions-boundary, the API call fails immediately with AccessDenied.
• Statement 2 (AllowPolicyAttachmentToBoundedRoles): Restricts policy attachment. Even if a role was created with a boundary, developers must not be allowed to attach policies to unbounded roles (such as existing security administration roles).
• Statement 3 (PreventBoundaryTampering): Explicitly denies removing or changing the boundary once a role is created.
• Statement 4 (PreventBoundaryPolicyModification): Crucial security safeguard. If a developer has permission to create a new default policy version (iam:CreatePolicyVersion) for the boundary policy, they could simply edit the boundary to allow *:*. Denying modification APIs on the boundary ARN closes this backdoor.
• Statement 5 (AllowPassRoleToApprovedServices): Restricts iam:PassRole so developers can only pass bounded roles to specific services like AWS Lambda and Amazon ECS, preventing them from passing roles to unauthorized compute instances.

2. The Permission Boundary Policy (AppPermissionBoundary)

The boundary policy defines the broad capabilities application workloads are permitted to use, while establishing permanent enterprise guardrails:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowApplicationServices",
      "Effect": "Allow",
      "Action": [
        "s3:*",
        "dynamodb:*",
        "sqs:*",
        "sns:*",
        "logs:*"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DenySecurityServicesModification",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:DeleteTrail",
        "cloudtrail:StopLogging",
        "cloudtrail:UpdateTrail",
        "guardduty:DeleteDetector",
        "guardduty:DisassociateFromMasterAccount",
        "securityhub:DisableSecurityHub",
        "config:DeleteConfigRule"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DenyIAMManagement",
      "Effect": "Deny",
      "Action": [
        "iam:*",
        "organizations:*"
      ],
      "Resource": "*"
    }
  ]
}

Even if a developer attaches AdministratorAccess (*:*) to an application role, the role can never modify CloudTrail, disable GuardDuty, alter AWS Config rules, or execute IAM API calls because those actions are explicitly denied by the boundary.

---

Boundary Limitations & Architectural Edge Cases

Understanding where permission boundaries do not apply is a major focus of specialty certification scenarios:

1. Resource-Based Policies Depend on the Principal Named: In the same account, a bucket or queue policy that names the role ARN is still limited by the role's boundary. A policy that names a role session ARN or an IAM user ARN grants access directly, even if the boundary omits the service. Cross-account access always needs the boundary (and identity policy) to allow the action.
2. Boundaries Do Not Grant Access: Attaching a permission boundary granting s3:* to a role that has no identity policies attached results in zero access. A matching identity-based policy must be attached.
3. Root User and Service-Linked Roles: Permission boundaries cannot be attached to the AWS account root user, nor do they apply to AWS service-linked roles created by AWS services to manage infrastructure.
4. Cross-Account Roles: When a principal in Account A assumes a cross-account role in Account B, any permission boundary attached to the principal in Account A has no effect on actions performed in Account B. The role in Account B is evaluated based on its own policies and any boundary attached directly to the Account B role.

---

Specialty Exam Pitfalls & Architectural Traps

1. The Policy Versioning Escalation Trap: When constructing delegation policies, never grant iam:CreatePolicyVersion on all policies. If a delegated user has iam:CreatePolicyVersion on *, they can update the boundary policy itself to add AdministratorAccess, bypassing all protections. Always deny policy versioning and deletion on the boundary policy ARN.
2. The iam:PassRole Without Boundary Trap: Granting iam:PassRole with Resource: "*" allows an engineer to create a Lambda function or EC2 instance and attach a pre-existing administrative role (e.g., OrganizationAccountAccessRole), thereby executing arbitrary code as full administrator. Always restrict iam:PassRole to roles within the approved path /app-roles/* that carry the boundary.
3. Confusing Permission Boundaries with SCPs: Service Control Policies apply account-wide across all principals (except the management account) and are managed at the AWS Organizations level. Permission boundaries are attached individually to specific IAM users and roles within an account. SCPs enforce compliance across accounts; boundaries enable safe delegation within an account.
4. The iam:PutRolePolicy Backdoor: Security engineers often enforce boundaries on iam:CreateRole but forget to condition iam:PutRolePolicy (inline policies) and iam:AttachRolePolicy (managed policies). Without conditioning policy attachment APIs, an engineer can create a bounded role, delete its boundary (if not denied), or attach policies to unmonitored existing roles.