Delegated role creation: constrain both the new role and its use

Last updated: 5 Oct 20266 min read

tutorial

Permission to create a role is not the same as permission to run a workload with it. A role's trust policy determines who can assume it, its identity policy determines what it can do, a permissions boundary caps grants from identity policies, and a PassRole permission controls which role a caller may hand to a service. Safe delegation needs constraints at each step. A boundary does not itself grant the new role an action, and the delegating principal must be prevented from removing or replacing that boundary.

Operational decision

A platform pipeline creates one worker role for each archive processor. Require a reviewed boundary at role creation and prevent the pipeline from editing or deleting that boundary policy. Limit role names and paths to the pipeline's namespace, restrict attachment to approved policies, restrict PassRole to those roles, and tie PassRole to the intended compute service. Require a trust policy that names that service rather than an arbitrary account principal. In a disposable account, attempt to create a role without the boundary, attach a broader policy, pass an unrelated administrator role, and change the role trust to an external account; each attempt should fail. Then deploy the intended worker and verify it can read its queue and write only its output prefix. Review the role after deployment, because a controller may mutate or replace resources after the initial plan. Where a service creates its own service-linked role, treat that as a separate path rather than assuming the worker-role rule covers it. Record who can update the boundary and who can pass the resulting role; separating these authorities matters more than a reassuring role name.

Archive worker delegation gate
CreateRole: approved path and mandatory boundary
Boundary changes: denied to workload pipeline
AttachPolicy: reviewed policy set only
PassRole: approved worker role and intended compute service
Trust: exact service principal, tested by assume attempt
Negative tests: no-boundary, admin-role pass, external trust

Cost and verification

With R delegated roles, inventory and drift review are O(R) in role records, while permission testing adds service-specific API calls. A boundary reduces possible authority but adds policy maintenance: changing it can break many roles at once. Measure unbounded-role count, PassRole grants outside approved paths, deployment denials, and drift from reviewed trust policies. A successful role create call is not proof the resulting workload is confined.

Common Mistakes

Do not grant PassRole over every role to simplify a deployment.
Do not let the creator remove the boundary that constrains its own creations.
Do not treat a role's trust policy as a substitute for its permissions policy.

Connected lessons

Practice and check

devops

cloud-security