IAM permission boundaries delegated administration is the privilege-escalation control SOC 2 reviewers sample when they ask "who can create roles?" An app team that can attach AdministratorAccess to a new role is org-admin, even if their own user looks limited. A permissions boundary is a ceiling: the new role cannot exceed it, no matter what identity policy someone attaches. AWS documents permissions boundaries as an advanced IAM feature that limits the maximum permissions a principal can have (IAM permissions boundaries).
Rutagon implements that ceiling so platform can vend iam:CreateRole to application accounts without vending the org. We do not hold a SOC 2 report. We do not hold FedRAMP authorization. We hold the Terraform that makes "delegated admin" a bounded verb.
Why Delegation Without a Ceiling Fails
IAM evaluates identity policies and the boundary (and SCPs, and session policies). The effective permission is the intersection. If a developer can create a role with no boundary and attach an inline *, they have escaped. CloudTrail will show CreateRole and PutRolePolicy. The auditor will ask who was allowed to do that. "Developers in the app account" is a finding if that means unbounded IAM write.
NIST SP 800-53 Rev. 5 AC-6 is least privilege (NIST SP 800-53 Rev. 5). SCPs at the OU are the org-level deny. Boundaries are the in-account deny for people you want to create roles. Use both. SCPs alone cannot express "you may create roles but only this shape." Boundaries can.
This is the same family as AWS Organizations SCP least privilege and Control Tower guardrails. Capability: AWS cloud infrastructure. Human access still belongs on Identity Center, not IAM users — SOC 2 ready AWS architecture.
IAM Permission Boundaries Delegated Administration We Ship
The platform account owns a managed policy AppRoleBoundary that allows typical app actions (logs, a named DynamoDB prefix, a named bucket prefix, kms:Decrypt on listed keys) and explicitly denies IAM write, Organizations, CloudTrail stop, and GuardDuty disable.
The delegated admin role — assumed by CI or by a platform-approved human permission set — has iam:CreateRole / iam:AttachRolePolicy only if iam:PermissionsBoundary equals that policy ARN. AWS supports this with a condition key.
data "aws_iam_policy_document" "delegate_create_role" {
statement {
sid = "CreateOnlyWithBoundary"
effect = "Allow"
actions = ["iam:CreateRole", "iam:AttachRolePolicy", "iam:PutRolePolicy"]
resources = ["arn:aws:iam::${var.account_id}:role/app-*"]
condition {
test = "StringEquals"
variable = "iam:PermissionsBoundary"
values = [aws_iam_policy.app_boundary.arn]
}
}
statement {
sid = "PassRoleBounded"
effect = "Allow"
actions = ["iam:PassRole"]
resources = ["arn:aws:iam::${var.account_id}:role/app-*"]
condition {
test = "StringEquals"
variable = "iam:PassedToService"
values = ["lambda.amazonaws.com", "ecs-tasks.amazonaws.com"]
}
}
}
PassRole without a service condition is how a bounded role still gets handed to a service that the team should not use. We pin services. We pin the name prefix. We deny iam:DeleteRolePermissionsBoundary on the delegated role.
CI that assumes this delegate role via OIDC is the usual path — workload identity federation. Humans who need to mint a role for an incident use a short Identity Center set, ticketed.
What Reviewers Sample
Expect:
- The boundary policy text
- The condition on
CreateRole - A CloudTrail sample of
CreateRoleshowing the boundary attached - A failed attempt (or a test) to create a role without the boundary
- Proof that
AdministratorAccesscannot be attached in a way that exceeds the ceiling
We keep a small "break the boundary" test in CI that expects AccessDenied. That test is evidence. A wiki that says "we use boundaries" is not.
Exceptions — a role that must deploy CloudFormation with broader IAM — live in the platform account, not in the app team's permission set. Named, reviewed, not copied.
What We Will Not Do
We will not hand every engineer iam:* with a boundary "to move fast." The create path is CI. We will not pretend a boundary replaces SCPs. We will not write a privilege-escalation cookbook. We will show you whether CreateRole in the app account is already unbounded.
Service-linked roles and AWS-managed service roles sit outside this pattern. We do not wrap those in app-* prefixes. The delegated policy should not need to create them. If an app team thinks they need iam:CreateServiceLinkedRole for every AWS service, that is a platform ticket, not a permission we sprinkle on the delegate role.
Terraform state that applies IAM in the app account must assume the delegate role, not a human admin permission set. Otherwise the boundary condition is theater: the human path still mints unbounded roles in the console. We watch CloudTrail for CreateRole events missing PermissionsBoundary. That metric is the operational control after the Terraform lands.
Permission boundary updates are production changes. Widening the ceiling to "fix a deploy" is how the ceiling disappears. We version the boundary policy and require a platform review to change it. App teams request new actions as tickets, not as drive-by policy edits.
IAM Access Analyzer unused-access findings on the delegated role are a useful check: if the delegate never uses PutRolePolicy, remove it. The create path should be as small as the team actually needs. Analyzer is not a substitute for the boundary condition; it is how the delegate role itself stays least-privilege.
Multi-account orgs attach the same boundary pattern per app account, with the policy ARN in that account. A centralized "one boundary in the management account" story usually fails because IAM policies are account-scoped. We stamp the pattern with Terraform. We do not copy-paste JSON by hand into twelve accounts and hope they stay identical. Drift between stamped member-account boundaries is itself a finding: one app account's ceiling grew and nobody reviewed it. The platform Terraform pipeline is the only writer of that ceiling policy.
Discuss delegated IAM administration with a ceiling →
907-841-8407 · contact@rutagon.com
Frequently Asked Questions
Do IAM permission boundaries replace SCPs?
No. SCPs are the org ceiling. Boundaries are the in-account ceiling for delegated role creation. You want both if app teams can mint roles.
Can a boundary be bypassed with an inline policy?
The boundary still intersects. An inline * cannot exceed the boundary. The bypass to worry about is creating a role without a boundary. That is what the condition key prevents.
Should every role in the account have a boundary?
Every role the delegated path can create, yes. Break-glass and platform roles live outside that path and stay tightly owned.
Does this work with IAM Identity Center permission sets?
Permission sets are for humans. Boundaries are usually on the workload roles those humans or CI create. Do not confuse the two. Humans should not be standing IAM users.
Is this a FedRAMP control?
It is least-privilege architecture. It is not an authorization. Rutagon does not hold FedRAMP or SOC 2. Your auditor may still sample it as CC6 design and operation.