IAM Role Chaining Through Lambda PassRole Wildcards
A deployment role that can pass any IAM role to a Lambda function inherits whatever that role can reach next, because AWS evaluates each sts:AssumeRole hop against the target's trust policy alone. Wildcarded principal patterns turn a single PassRole grant into a multi-hop climb toward administrator access that no PassRole audit alone will catch.
At a glance
- Unsafe setting
- iam:PassRole with Resource "*" and no iam:PassedToService condition, paired with path-wildcarded principals in role trust policies.
- Failure trigger
- A deploy identity passes an existing role to a new Lambda function, then that role's trust relationship permits AssumeRole into a higher-privileged role via wildcard principal matching.
- Blast radius
- A limited CI/CD identity escalates through a multi-hop AssumeRole chain to reach an administrator-level role, with each hop logged separately and individually plausible.
- Recommended control
- Scope PassRole with iam:PassedToService and explicit ARNs, replace wildcard trust principals with named ARNs, and enforce a session-tag-based SCP that blocks untagged cross-role assumption.
The Trap
iam:PassRole with Resource “*” and no iam:PassedToService condition, combined with cross-role trust policies that accept wildcarded principal patterns such as arn:aws:iam::ACCOUNT:role/service-role/*. Together these two settings let a low-privilege CI/CD identity climb through a chain of roles rather than escalate through a single grant.
The Default State
Console-generated Lambda execution roles and the AWSLambda_FullAccess managed policy both attach iam:PassRole with an unrestricted Resource value, on the assumption that scoping is handled elsewhere. Separately, platform teams onboarding new service roles commonly write trust policies using a path-based wildcard principal (role/service-role/*) so they don’t have to edit the policy every time a new Lambda role is created. Neither setting looks dangerous in isolation during a policy review.
The Blast Radius
A pipeline identity limited to lambda:CreateFunction and lambda:UpdateFunctionConfiguration passes an existing role, R1, to a new function. R1’s own permissions are modest, but its trust relationship lets it call sts:AssumeRole on R2, whose trust policy accepts any principal matching the same service-role/* path pattern R1 happens to sit under. R2 carries AdministratorAccess because it was scoped for a legitimate automation use case years earlier. The function code executes AssumeRole against R2, retrieves session credentials, and the deploy pipeline now has account-wide administrative reach. Because CloudTrail logs each AssumeRole call as a separate, individually plausible event, no single log line reveals the chain; only correlating AssumeRole sessions across roles exposes it.
The Lead Mechanic Fix
Attach a condition to every PassRole statement: “Condition”: {“StringEquals”: {“iam:PassedToService”: “lambda.amazonaws.com”}}, and replace Resource “*” with explicit role ARNs or an ABAC tag condition such as aws:ResourceTag/deploy-scope. Rewrite trust policies to name exact role ARNs instead of path wildcards, then run IAM Access Analyzer’s unused-access findings against every role permitted to assume another role. Add an SCP denying sts:AssumeRole where aws:ViaAWSService is absent and the target role’s tag lacks a matching session tag, breaking the transitive hop at the organisation boundary rather than per account.
Apply the safer control
Before you change production
Confirm the affected scope, export the current configuration, and test the replacement control in a non-production environment first.
Scope PassRole with iam:PassedToService and explicit ARNs, replace wildcard trust principals with named ARNs, and enforce a session-tag-based SCP that blocks untagged cross-role assumption.
Validate the vendor-specific syntax in official documentation before applying it.
Verify, roll back or escalate
Verify
Re-run the detection test and a controlled negative-path test. Confirm the unsafe behaviour is blocked while approved traffic still succeeds.
Rollback
Restore the exported configuration if the new control blocks required production traffic, then narrow the policy before redeployment.
Escalate
Escalate when the blast radius is uncertain, the control cannot be tested safely, or remediation requires an outage or security exception.