fix(lambda): read the execution role's trust policy in the role's account - #2637
Merged
Merged
Conversation
There was a problem hiding this comment.
Copilot review overview
🟢 Approval recommended
The implementation matches the established ECS behavior and includes focused regression coverage for every affected Lambda path.
Review effort: Balanced
Findings: None
What changed in this PR
Fixes Lambda cross-account execution-role validation by reading the trust policy from the role owner’s account.
Changes:
- Resolves trust validation using the role ARN’s account.
- Adds Lambda and CloudFormation regression coverage.
- Clarifies Lambda service documentation.
| File | Description |
|---|---|
website/content/docs/services/lambda.md |
Documents trust-policy account resolution. |
crates/fakecloud-lambda/src/service/mod.rs |
Fixes execution-role validation. |
crates/fakecloud-lambda/src/service/functions.rs |
Updates PassRole commentary. |
crates/fakecloud-lambda/src/service_tests.rs |
Tests create, update, strict, and cross-account behavior. |
crates/fakecloud-cloudformation/src/resource_provisioner/mod.rs |
Tests CloudFormation’s cross-account role handling. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
All reported issues were addressed across 5 files
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
There was a problem hiding this comment.
All reported issues were addressed across 5 files (changes from recent commits).
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
…ount validate_execution_role looked a role's trust policy up in the caller's account, so for another account's role ARN (allowed with IAM off or soft) a same-named role in the caller's account was checked instead of the role the ARN names. Resolve the role in the account its ARN names, falling back to the caller's when it names none, as ECS's validate_task_role does. CreateFunction, UpdateFunctionConfiguration and CloudFormation AWS::Lambda::Function share the check. Strict mode still refuses another account's role before the trust policy is read. Closes #2634
A cross-account execution role is minted in the function's account (as the same-named role there), so with IAM off or soft that role's trust policy must allow Lambda too, not only the one the ARN names. Share the re-homing between the trust check and the session minting.
…les in the trust double
vieiralucas
force-pushed
the
fix-lambda-role-trust-account
branch
from
October 1, 2026 17:20
1341913 to
5b2218f
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
validate_execution_rolelooked the role's trust policy up in the caller's account. For another account's role ARN (accepted with IAM off or--iam soft), a same-named role in the caller's account was checked instead of the role the ARN names. It now resolves the role in the account its ARN names (falling back to the caller's when it names none), mirroringfakecloud_ecs::validate_task_rolefrom ECS credentials endpoint returns static credentials instead of a task-role session #2601.session_role_arn, deliberate since feat(lambda): give function containers the AWS environment #2562 so000000000000templates route SDK calls to the function's account). So for a cross-account role the same-named role in the function's account, the one actually assumed, must also trust Lambda. Both checks run; the re-homing (role_in_account) is shared between the check and the minting so they cannot drift.AWS::Lambda::Functionshare the function, so all three are fixed.--iam strictis unchanged and matches ECS's structure: another account's role is refused before any trust policy is read (Lambda'sAccessDeniedException: Cross-account pass role is not allowed.); soft audits and allows.RoleTrustValidator::validate; no other service has this bug.Test plan
cargo test -p fakecloud-lambda --lib:another_accounts_role_is_checked_against_its_own_trust_policy(two accounts, same-named role, each trust combination, strict mode asserts the validator is never consulted),create_and_update_function_check_both_accounts_roles(CreateFunction + UpdateFunctionConfiguration handlers),trust_check_runs_in_the_roles_account(lookup accounts + no-account fallback),role_in_account_rehomes_only_arns_naming_an_account,session_is_minted_in_the_function_accountcargo test -p fakecloud-cloudformation --lib lambda_function_role:lambda_function_role_trust_is_read_in_both_accountswith real IAM state holdingrole/appin two accounts; confirmed the foreign-untrusting case fails with the old lookupcargo clippy --workspace --all-targets -- -D warnings,cargo fmt --all --checkCloses #2634