Repository navigation
fix(content): cover STS cross-partition federation (2026-11) - #23
Conversation
Credentials still do not cross partitions directly, but since 2026-11-09 a GetWebIdentityToken JWT can be exchanged with AssumeRoleWithWebIdentity in another partition. Replace the "credentials never cross partitions" claim, add the timeline entry and the aws:CrossPartitionSourceRegion key, and bump the as-of date after re-checking the monthly freshness list.
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars.
 |
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
| @@ -1,2 +1,2 @@ | |||
| /** Date the facts on the site were last checked against AWS documentation. */ | |||
| export const AS_OF = "2026-10-10"; | |||
| export const AS_OF = "2026-11-11"; | |||
There was a problem hiding this comment.
AS_OF is set to 2026-11-11, but the PR was authored on 2026-11-10, so the site footer would claim facts were checked on a day that hasn't happened. The same date is repeated in README.md:30, README.ja.md:30, and the "Last verified" lines of docs/02, 05 and 07. Use the actual verification date.
The bump also overstates what was checked. Only the cross-partition material was re-verified. The "as of 2026-10-10" statements in ops.ts:4, regions.ts:4, sdk.ts:7 and DepartureBoard.tsx:33 (34 Regions, 11 ops) were not re-checked, yet the footer and READMEs now say everything was checked on the new date.
There was a problem hiding this comment.
The date is right in local time (JST): it was already 2026-11-11 here when this was checked. The other half was fair. The 11 operations, 34 commercial Regions and the SDK defaults table were re-read today and are unchanged, so their as-of markers in ops.ts, regions.ts, sdk.ts, DepartureBoard.tsx and docs/02 now say 2026-11-11 too (6f116df). The VPC endpoint list (33 Regions) was not re-checked, so that one keeps 2026-10-10.
| - Parameters: `Audience` 1 to 10 values; `DurationSeconds` 60 to 3600, default 300; `SigningAlgorithm` `RS256` or `ES384` (required); up to 50 `Tags`. Not available on the STS global endpoint. Errors include `OutboundWebIdentityFederationDisabled` and `SessionDurationEscalation` (a token cannot outlive the calling session) ([API reference](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetWebIdentityToken.html)). | ||
| - Claims: standard `iss`, `aud`, `sub` (principal ARN), `iat`, `exp`, `jti`; under the `https://sts.amazonaws.com/` namespace: `aws_account`, `source_region`, `org_id`, `ou_path`, `principal_tags`, `request_tags`, and context such as `ec2_source_instance_arn`, `ec2_instance_source_vpc`, `ec2_role_delivery`, `lambda_source_function_arn`, `identity_store_user_id`, `federated_provider`, `source_identity`, `original_session_exp`, `glue_credential_issuing_service` ([token claims](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_outbound_token_claims.html)). | ||
| - Control: `sts:GetWebIdentityToken` permission plus condition keys `sts:IdentityTokenAudience`, `sts:SigningAlgorithm`, `sts:DurationSeconds`, usable in identity policies, SCPs, RCPs and VPC endpoint policies ([AWS News Blog](https://aws.amazon.com/blogs/aws/simplify-access-to-external-services-using-aws-iam-outbound-identity-federation/)). | ||
| - Cross-partition (since 2026-11): the destination partition's STS can be the relying party. Create an IAM OIDC provider there for the source account's issuer URL, request the token with exactly one `Audience`, and call `AssumeRoleWithWebIdentity` at a Regional endpoint in the destination partition. Tokens are rejected for `AssumeRoleWithWebIdentity` in the same partition (use `AssumeRole`). Session requests carry `aws:CrossPartitionSourceRegion`; CloudTrail links both sides through `webIdentityTokenId` ([IAM User Guide](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_outbound_cross_partition.html), [What's New](https://aws.amazon.com/about-aws/whats-new/2026/11/aws-sts-cross-partition/)). |
There was a problem hiding this comment.
Two claims here aren't in the cited IAM page that I could see: "exactly one Audience" (the bullet above says 1 to 10 values), and "Session requests carry aws:CrossPartitionSourceRegion" / the webIdentityTokenId CloudTrail link. They may be on the setup, controls or auditing subpages. If so, cite those pages (the docs promise sourced claims, or "(unverified)"). Otherwise mark them "(unverified)". The same applies to "Not transitive through role chaining" in src/features/trust/catalog.ts:378 and "not in the trust policy" at :373.
There was a problem hiding this comment.
All are on the subpages. 6f116df cites setup and controls for the single audience (the 1 to 10 range is the general API limit; cross-partition rejects tokens with more than one), the global condition keys page for aws:CrossPartitionSourceRegion (present only for cross-partition role sessions, not in the trust-policy evaluation, not transitive), and the auditing page for webIdentityTokenId. The key is also added to the docs/04 catalogue that catalog.ts points to.
|
Review summary
|
Address review: cite the setup, controls, auditing and condition-key pages for the single-audience rule, aws:CrossPartitionSourceRegion and the webIdentityTokenId link; add the key to the docs/04 catalogue; move the as-of markers for the 11 operations, 34 Regions and the SDK defaults table to 2026-11-11, which were re-checked and unchanged.
| @@ -1,2 +1,2 @@ | |||
| /** Date the facts on the site were last checked against AWS documentation. */ | |||
| export const AS_OF = "2026-10-10"; | |||
| export const AS_OF = "2026-11-11"; | |||
There was a problem hiding this comment.
AS_OF is set to 2026-11-11, which is after today (2026-11-10). A "checked on" date can't be in the future. The same date is used in both READMEs, docs/02, 05, 07, DepartureBoard.tsx, ops.ts and regions.ts. Use the real verification date.
The refresh is also partial. docs/README.md:3, docs/01-overview.md:3 and docs/03-api-operations.md:3 still say 2026-10-10, but ops.ts now claims "11 as of 2026-11-11" and cites docs/03. The site and README therefore say the facts were checked on 2026-11-11 while the docs they point to say 2026-10-10. Either re-check those files and bump them, or don't bump the global date.
There was a problem hiding this comment.
Same as before: the date is local (JST), where it is already 2026-11-11; the runner reads UTC. docs/03 was re-checked (the API Reference was last published 2026-11-10 with the same 11 actions) and now says 2026-11-11. docs/01 and docs/README are summaries of the deep dives and keep their original research date.
| | `aws:userid` | String | Always | See 10.4 | | ||
| | `aws:PrincipalArn` | ARN | Signed requests | Matches the **role** ARN for role sessions; not converted to unique IDs | | ||
| | `aws:AssumedRoot` | Bool | Credentials from `AssumeRoot` only | Distinguish centralized root sessions | | ||
| | `aws:CrossPartitionSourceRegion` | String | Role sessions from cross-partition federation (`AssumeRoleWithWebIdentity` with a `GetWebIdentityToken` JWT); not in the trust-policy evaluation; not transitive through role chaining | SCP/RCP/identity-policy deny by the Region that issued the token (in the trust policy, use `issuer-host:source_region`) | |
There was a problem hiding this comment.
Several specifics in this row read as recalled rather than sourced, and no link is given in the row:
- "not in the trust-policy evaluation"
- "not transitive through role chaining"
- the
issuer-host:source_regiontrust-policy form
The row also contradicts itself: it says the key isn't in trust-policy evaluation, then says to use issuer-host:source_region in the trust policy. Cite the condition-keys page or the ..._cross_partition_controls page here and make the two statements consistent. Also, docs/05 cites reference_policies_condition-keys.html only for the key's existence. If the other claims aren't confirmed, mark them "(unverified)" per the doc convention.
There was a problem hiding this comment.
These are from the global condition keys page, which says the key "is not available when the role trust policy is evaluated for the AssumeRoleWithWebIdentity call. To restrict the source AWS Region before credentials are returned, use the issuer-host:source_region condition key in the role trust policy" and "This key is not transitive." So the two parts don't conflict: one key is for policies on the session, the other is for the trust policy. The row now says that and links the condition-keys and cross-partition controls pages (6faea43).
| ### Other partitions | ||
|
|
||
| Credentials never cross partitions. The AWS European Sovereign Cloud landing-zone guidance states plainly that `sts:AssumeRole` is "Not available across the aws and aws-eusc boundary" ([AWS Security Blog: ESC landing zone](https://aws.amazon.com/blogs/security/architecting-a-secure-landing-zone-in-the-aws-european-sovereign-cloud/)). Non-commercial partitions "must use Regional endpoints" ([SDK Reference](https://docs.aws.amazon.com/sdkref/latest/guide/feature-sts-regionalized-endpoints.html)). | ||
| A credential issued in one partition is not valid in another, so `AssumeRole` does not work across a partition boundary. The AWS European Sovereign Cloud landing-zone guidance states plainly that `sts:AssumeRole` is "Not available across the aws and aws-eusc boundary" ([AWS Security Blog: ESC landing zone](https://aws.amazon.com/blogs/security/architecting-a-secure-landing-zone-in-the-aws-european-sovereign-cloud/)). Since November 2026 the supported way across is cross-partition identity federation: call `GetWebIdentityToken` in the source partition and exchange the JWT with `AssumeRoleWithWebIdentity` at a Regional endpoint in the destination partition (`aws`, `aws-cn`, `aws-us-gov`, `aws-eusc`; [IAM User Guide](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_outbound_cross_partition.html), [What's New](https://aws.amazon.com/about-aws/whats-new/2026/11/aws-sts-cross-partition/)). Non-commercial partitions "must use Regional endpoints" ([SDK Reference](https://docs.aws.amazon.com/sdkref/latest/guide/feature-sts-regionalized-endpoints.html)). |
There was a problem hiding this comment.
"Since November 2026" is stated as fact. The timeline entries are dated only to the month, and this sentence is a launch claim sourced to What's New URLs. Please confirm the launch date and that all four partitions (aws, aws-cn, aws-us-gov, aws-eusc) are supported at launch.
"Credentials never cross partitions" was dropped here, but AssumeRole across partitions is still unsupported. The new wording is fine, but the site UI (decide.ts) and the glossary now describe the exchange as an available route without any "(unverified)" marker if the page couldn't be fetched.
There was a problem hiding this comment.
What's New was posted 2026-11-09. The IAM User Guide note lists aws, aws-cn, aws-us-gov and aws-eusc, and What's New lists the same four (commercial, GovCloud (US), China, European Sovereign Cloud). Both are linked in the sentence, so no unverified marker is needed.
|
Review of the cross-partition federation content update.
EN/JA content is consistent in the changed strings. No workflow or injection surface is touched. |
| @@ -1,2 +1,2 @@ | |||
| /** Date the facts on the site were last checked against AWS documentation. */ | |||
| export const AS_OF = "2026-10-10"; | |||
| export const AS_OF = "2026-11-11"; | |||
There was a problem hiding this comment.
AS_OF is set to 2026-11-11, but the check happened on or before 2026-11-10, so the date is in the future. The same date is repeated as "checked/verified" in README.md:30, README.ja.md:30, docs/02, 03, 05, 07, the DepartureBoard hint and the ops/regions/sdk comments. Use the real date of the re-check.
There was a problem hiding this comment.
Same as the earlier threads: 2026-11-11 is the local (JST) date of the re-check, so no change.
| en: "China, GovCloud, the European Sovereign Cloud and ISO partitions have no global endpoint. Use that partition's Regional endpoint; credentials never cross partitions.", | ||
| ja: "中国・GovCloud・European Sovereign Cloud・ISO にはグローバルエンドポイントがありません。そのパーティションのリージョナルを使います。認証情報はパーティションをまたげません。", | ||
| en: "China, GovCloud, the European Sovereign Cloud and ISO partitions have no global endpoint. Use that partition's Regional endpoint. Credentials from one partition are not valid in another; to reach another partition, exchange a `GetWebIdentityToken` JWT with `AssumeRoleWithWebIdentity` there (cross-partition federation, since November 2026).", | ||
| ja: "中国・GovCloud・European Sovereign Cloud・ISO にはグローバルエンドポイントがありません。そのパーティションのリージョナルを使います。あるパーティションの認証情報は別のパーティションでは無効です。別パーティションに入るには、`GetWebIdentityToken` の JWT を相手側の `AssumeRoleWithWebIdentity` で交換します (2026 年 11 月からのクロスパーティションフェデレーション)。", |
There was a problem hiding this comment.
This branch also covers "ISO partitions", but the cross-partition route is documented only for aws, aws-cn, aws-us-gov and aws-eusc (see docs/02). "To reach another partition, exchange..." therefore overstates it for ISO users. Say the route applies to those four partitions, in both EN and JA.
There was a problem hiding this comment.
Right, the ISO partitions are not in the documented list. Fixed in a follow-up, since this PR was already merged: the sentence now names the four partitions and says AWS does not document the route for ISO.
| - Parameters: `Audience` 1 to 10 values; `DurationSeconds` 60 to 3600, default 300; `SigningAlgorithm` `RS256` or `ES384` (required); up to 50 `Tags`. Not available on the STS global endpoint. Errors include `OutboundWebIdentityFederationDisabled` and `SessionDurationEscalation` (a token cannot outlive the calling session) ([API reference](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetWebIdentityToken.html)). | ||
| - Claims: standard `iss`, `aud`, `sub` (principal ARN), `iat`, `exp`, `jti`; under the `https://sts.amazonaws.com/` namespace: `aws_account`, `source_region`, `org_id`, `ou_path`, `principal_tags`, `request_tags`, and context such as `ec2_source_instance_arn`, `ec2_instance_source_vpc`, `ec2_role_delivery`, `lambda_source_function_arn`, `identity_store_user_id`, `federated_provider`, `source_identity`, `original_session_exp`, `glue_credential_issuing_service` ([token claims](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_outbound_token_claims.html)). | ||
| - Control: `sts:GetWebIdentityToken` permission plus condition keys `sts:IdentityTokenAudience`, `sts:SigningAlgorithm`, `sts:DurationSeconds`, usable in identity policies, SCPs, RCPs and VPC endpoint policies ([AWS News Blog](https://aws.amazon.com/blogs/aws/simplify-access-to-external-services-using-aws-iam-outbound-identity-federation/)). | ||
| - Cross-partition (since 2026-11): the destination partition's STS can be the relying party. Create an IAM OIDC provider there for the source account's issuer URL, request the token with exactly one `Audience` (multi-audience tokens are rejected; [setup](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_outbound_cross_partition_setup.html), [controls](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_outbound_cross_partition_controls.html)), and call `AssumeRoleWithWebIdentity` at a Regional endpoint in the destination partition. Tokens are rejected for `AssumeRoleWithWebIdentity` in the same partition (use `AssumeRole`). Session requests carry `aws:CrossPartitionSourceRegion` ([global condition keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)); CloudTrail links both sides through `webIdentityTokenId` ([auditing](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_outbound_cross_partition_auditing.html), [IAM User Guide](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_outbound_cross_partition.html), [What's New](https://aws.amazon.com/about-aws/whats-new/2026/11/aws-sts-cross-partition/)). |
There was a problem hiding this comment.
Some claims here read as recalled rather than sourced: the single-Audience restriction, "tokens are rejected for AssumeRoleWithWebIdentity in the same partition", and webIdentityTokenId in CloudTrail. The linked pages (setup, controls, auditing) are not among the sources the PR body lists, and I could not confirm them from the repo. Confirm each against the cited page, or mark it "(unverified)" per the docs convention.
There was a problem hiding this comment.
These were read from the cited pages before 6faea43 added the links. The single audience is on the setup and controls pages ("AssumeRoleWithWebIdentity rejects tokens from GetWebIdentityToken that have more than one audience"). The same-partition rejection is on the main cross-partition page ("cannot be used for OpenID Connect (OIDC) federation into the same partition"). webIdentityTokenId is on the auditing page. No change.
|
Review of the cross-partition federation change. Findings are posted inline, except the stale dates in the docs index files, which are listed here.
EN/JA parity is fine in the changed strings. |
Since 2026-11-09, STS supports cross-partition federation: a workload calls
GetWebIdentityTokenin its own partition and exchanges the JWT withAssumeRoleWithWebIdentityat a Regional endpoint in another partition (aws,aws-cn,aws-us-gov,aws-eusc). The site still said "credentials never cross partitions", which now reads as "there is no way across".Changes
docs/02: a credential from one partition is still not valid in another, andAssumeRolestill does not cross, but cross-partition federation is now the supported route.GetWebIdentityTokenpurpose (API chapter), glossary anddocs/05: the JWT can also go to STS in another partition.docs/05adds the setup and the same-partition restriction.docs/07): 2026-11 entry.aws:CrossPartitionSourceRegion.sts_regional_endpointsdefaults, the 4,096-byte token limit and GitHub's immutablesuball still match.Sources: What's New, IAM User Guide: Federating AWS identities across AWS partitions, IAM global condition keys.
Verification
npm run checklocally: typecheck, ESLint, Prettier, markdownlint, Vitest (34 files, 284 tests) and build pass. E2E is left to CI.Closes #13