Live
Hardening GitOps Pipelines for AI‑Driven Change SafetyIntegrating Meta’s Muse Ember: Cost‑Effective Multimodal Model for Agentic TasksFable 5.2 coding performance boost and pricing shift: what engineers need to knowMulti‑Agent LLM Batch Pipelines Cut Walmart’s Cloud Inference Spend Ten‑foldDeploying NVIDIA Nemotron 3.5 Super VL on SageMaker JumpStart: Practical Implications for EngineersUsing the Rust Flagship SDK for Feature Flag Evaluation in Async ServicesDeploying Open‑Weight Models on Kubernetes with the New AI‑Native StackClaude Fable 5.2 on Amazon Bedrock: Implications for Engineering and OperationsHardening GitOps Pipelines for AI‑Driven Change SafetyIntegrating Meta’s Muse Ember: Cost‑Effective Multimodal Model for Agentic TasksFable 5.2 coding performance boost and pricing shift: what engineers need to knowMulti‑Agent LLM Batch Pipelines Cut Walmart’s Cloud Inference Spend Ten‑foldDeploying NVIDIA Nemotron 3.5 Super VL on SageMaker JumpStart: Practical Implications for EngineersUsing the Rust Flagship SDK for Feature Flag Evaluation in Async ServicesDeploying Open‑Weight Models on Kubernetes with the New AI‑Native StackClaude Fable 5.2 on Amazon Bedrock: Implications for Engineering and Operations
AWS

Enable cross‑partition access with AWS IAM outbound federation

Ninja·November 9, 2026·2 min read·via AWS Security Blog
AI SummaryPowered by AI

AWS now lets workloads obtain a JWT in one partition and exchange it for temporary credentials in another partition using outbound identity federation. This removes the need for long‑term credentials and lets engineers apply existing IAM policies across isolated AWS partitions.

AWS has added cross‑partition support to its outbound identity federation feature. A workload can call sts:GetWebIdentityToken in its native partition, receive a short‑lived signed JWT, and then call sts:AssumeRoleWithWebIdentity in a different partition to receive temporary credentials. This change matters because it eliminates the previous barrier where IAM credentials were confined to a single partition, forcing teams to manage separate credential sets or custom token bridges.

How the new flow works

The process consists of two STS calls:

  • In the source partition, the workload invokes sts:GetWebIdentityToken and receives a JWT signed by AWS.
  • The JWT is presented to STS in the destination partition via sts:AssumeRoleWithWebIdentity, which returns temporary access keys scoped to the requested role.

Both calls are short‑lived; no long‑term secrets are stored or rotated. The destination role’s trust policy can reference attributes of the source identity, such as the originating account, organization ID, region, or principal ARN.

Why engineers should care

Cross‑partition workloads—common in environments that span Commercial, China, GovCloud (US), or European Sovereign Cloud—can now use a single, managed token flow instead of building custom credential translation layers. The benefits listed by AWS include:

  • Origin identity in authorization decisions: Trust policies can condition on source attributes, enabling fine‑grained access control.
  • Unified audit trail: CloudTrail logs in the destination region capture the source ARN, region, and token ID, linking back to the source GetWebIdentityToken event.
  • End‑to‑end temporary credentials: Every step uses expiring tokens, reducing exposure risk.
  • Fully managed token issuance: AWS STS handles signing and key distribution, removing the need for a private PKI or external OpenID Provider.
  • Standard IAM integration: Existing role and policy constructs apply unchanged.
  • Session revocation: Issued sessions can be revoked by denying the destination role or adjusting trust conditions.

Operational and security implications

Adopting this flow introduces several considerations:

  • Policy design: Trust policies must be updated to accept the JWT’s audience and source attributes, and to enforce any compliance constraints.
  • Compliance review: Because cross‑partition data movement may be subject to regulations such as FedRAMP, ITAR, GDPR, or DoD SRG, teams should involve compliance owners before enabling the pattern.
  • Monitoring: CloudTrail entries now contain cross‑partition identifiers; alerting should be extended to watch for unexpected source ARNs or regions.
  • Credential lifecycle: Since sessions are short‑lived, automation that obtains and refreshes tokens must handle token expiry gracefully.
  • Revocation strategy: Organizations should define how to deny or rotate destination roles if a source compromise is detected.

Related CloudNinjas coverage: AWS.

What This Means For Practitioners

Engineers building multi‑partition solutions can replace ad‑hoc credential handling with a native AWS flow that leverages existing IAM roles and policies. The immediate action is to update workloads to call sts:GetWebIdentityToken in their home partition and to configure destination roles to trust the JWT, adding any required source‑based conditions. Simultaneously, security and compliance teams should audit the new trust relationships and extend monitoring to capture the cross‑partition audit data that CloudTrail now provides.

Tags: #aws#iam#sts#cross-partition#security
Originally published atAWS Security Blog
Related Articles
GitHub

Actions workflow log scanning enters public preview on GitHub

3 min read
AWS

AWS Account Access Manager: Centralized Role Assignment for Engineers

4 min read
GitHub

GitHub secret scanning adds SpaceX partner and refines false‑positive filters

3 min read