An application team wants to create its own IAM roles in an AWS account instead of filing tickets with the platform team, but must never be able to create a role with administrator permissions. How do you delegate iam:CreateRole safely, and what else must the delegation policy lock down?

## The problem IAM write permissions are the sharpest privilege-escalation surface in an AWS account. `iam:CreateRole` plus `iam:AttachRolePolicy` is functionally equivalent to `AdministratorAccess`: create a role, attach the admin policy, write a trust policy naming yourself, assume it. Any delegation of self-service IAM has to solve that problem or it is not a delegation, it is a grant of admin with extra steps. Permissions boundaries exist for exactly this case. The trick is that a boundary is a property of the created entity, and IAM exposes a condition key — `iam:PermissionsBoundary` — whose value is the ARN of the boundary attached to the entity the request is acting on. That lets the delegation policy demand: *you may perform this IAM write, but only against a role that carries this specific boundary.* ## The delegation policy, in three parts **1. Allow the creates and the policy writes, conditioned on the boundary.** ```json { "Effect": "Allow", "Action": ["iam:CreateRole", "iam:AttachRolePolicy", "iam:PutRolePolicy"], "Resource": "arn:aws:iam::111122223333:role/dev/*", "Condition": { "StringEquals": { "iam:PermissionsBoundary": "arn:aws:iam::111122223333:policy/DevBoundary" } } } ``` Two constraints are doing work here. The `Resource` limits them to a path they own, so they cannot rewrite the platform team's roles. The condition means a `CreateRole` without `--permissions-boundary arn:.../DevBoundary` is denied outright, and an `AttachRolePolicy` against a role that lacks that boundary is denied too — so they cannot bolt an admin policy onto some pre-existing unbounded role. **2. Deny anything that removes or weakens the cap.** ```json { "Effect": "Deny", "Action": [ "iam:DeleteRolePermissionsBoundary", "iam:PutRolePermissionsBoundary", "iam:DeleteUserPermissionsBoundary", "iam:PutUserPermissionsBoundary" ], "Resource": "*" } ``` This is the step teams forget, and it is the whole ballgame. Without it, the flow is: create a role with the boundary (allowed), then call `DeleteRolePermissionsBoundary` on the role you just created (also allowed, because nothing said otherwise), then attach admin. An explicit `Deny` closes it, and explicit denies cannot be overridden. **3. Protect the boundary policy document itself, and PassRole.** If the team can call `iam:CreatePolicyVersion` on the boundary policy's ARN, they can simply rewrite the ceiling to `"Action": "*"`. Deny writes to that ARN — `iam:CreatePolicyVersion`, `iam:DeletePolicyVersion`, `iam:SetDefaultPolicyVersion`, `iam:DeletePolicy`. `iam:PassRole` deserves its own thought. Creating a bounded role is safe; *handing an existing powerful role to a service* is not. If the team can pass an unrelated admin role to a Lambda function or an EC2 instance they control, the boundary on their own roles is irrelevant — they run code as that role instead. Scope `iam:PassRole` to the same path, and use the `iam:PassedToService` condition key to restrict which service may receive it. ## Writing the boundary itself The boundary is a normal policy document, but written as a ceiling: broad enough that teams rarely hit it for legitimate work, narrow enough to be meaningful. Typically it allows the application services the team needs (S3, DynamoDB, SQS, CloudWatch Logs) and pointedly omits the escalation surfaces — IAM writes, Organizations, account-level settings, key policy changes. Some teams add an explicit `Deny` inside the boundary for a small set of never-allowed actions, so the cap is legible even to someone skimming. Beware the temptation to make the boundary itself allow IAM writes "so the roles can manage themselves" — that reopens the hole one level down, because a bounded role that can create roles inherits the same problem unless the condition is applied there too. ## Verifying it Do not ship this on reasoning alone. Try the attacks: create a role without the boundary (expect denied), create one with it and try to strip the boundary (denied), attach `AdministratorAccess` to a bounded role and confirm the role still cannot call anything outside the cap (allowed to attach, useless in practice), and try to pass a privileged role to a service. The IAM policy simulator covers the static evaluation; a scratch account covers the rest. Pair it with monitoring on IAM write events so an unexpected boundary change is visible. ## Why this is the right shape The alternative — a central team reviewing every policy — does not scale and creates a queue that teams route around. The boundary shape moves the review from *every policy* to *one ceiling document*, reviewed rarely and carefully. That is the real argument to make in an interview: the mechanism converts an unbounded review burden into a bounded one.