Skip to content

fix(iam): build user and policy ARNs from the request's account - #2555

Merged
vieiralucas merged 1 commit into
mainfrom
fix/iam-user-policy-account-arn
Sep 24, 2026
Merged

vieiralucas merged 1 commit into
mainfrom
fix/iam-user-policy-account-arn

Conversation

@vieiralucas

@vieiralucas vieiralucas commented Sep 24, 2026 •

Copy link
Copy Markdown
Member

Summary

Fixes #2552.

CreateUser and CreatePolicy built their ARN from effective_account_id, a helper that predates multi-account isolation (#381). It only recognized STS session keys registered in credential_identities and otherwise fell back to the server's default account. Keys issued by /_fakecloud/iam/create-admin are not session keys, so users and customer-managed policies created in a non-default account got arn:aws:iam::123456789012:... while being stored in the caller's account, and the policy only resolved by that wrong ARN.

Both handlers now take the account from the partitioned state (state.account_id), the same source CreateRole and CreateGroup already use. The unused helper and IAM's copy of extract_access_key are removed.

No surface changes: this is a behavior fix with no new API, flag, or SDK field, so docs/SDKs/counts are unchanged.

Test plan

  • New e2e tests in multi_account.rs:
    • iam_entity_arns_use_non_default_account: a create-admin user in account B creates a user, policy, role, and group; every ARN names B; GetPolicy/AttachUserPolicy/GetUser resolve by the returned ARNs. Fails on main (arn:aws:iam::123456789012:user/alice).
    • iam_entity_arns_use_assumed_role_account: same assertions through an assumed-role session from A into B.
  • cargo test -p fakecloud-iam, e2e iam, iam_enforcement, iam_persistence, cloudformation_iam, multi_account: all pass.
  • cargo clippy -p fakecloud-iam -p fakecloud-e2e --all-targets -- -D warnings clean.

Summary by cubic

Fixes #2552 by making CreateUser and CreatePolicy build their ARNs from the partitioned state's account, matching what CreateRole and CreateGroup already do. The old helper only recognized STS session keys and otherwise fell back to the server's default account, so users and customer-managed policies created in a non-default account got arn:aws:iam::123456789012:... while being stored in the caller's account.

  • Removes the now-unused effective_account_id helper and IAM's extract_access_key.
  • Adds e2e tests asserting entity ARNs and policy resolution through both a create-admin credential and an assumed-role session in a non-default account.

Written for commit 78e76c3. Summary will update on new commits.

Review in cubic

CreateUser and CreatePolicy took the account for their ARN from a
pre-multi-account helper that only knew STS session keys and otherwise
fell back to the server's default account. Credentials issued by
/_fakecloud/iam/create-admin are not session keys, so users and
customer-managed policies created in a non-default account carried the
default account id and the policy only resolved by that wrong ARN.

Use the partitioned state's account, as CreateRole and CreateGroup
already do, and drop the now-unused helper.

Fixes #2552
@vieiralucas
vieiralucas requested a lite review from Copilot September 24, 2026 20:20

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

@vieiralucas
vieiralucas merged commit 0b9fa50 into main Sep 24, 2026
157 checks passed
@vieiralucas
vieiralucas deleted the fix/iam-user-policy-account-arn branch September 24, 2026 22:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

IAM users and managed policies get the default account id in their ARN in non-default accounts

2 participants