Cross-cloud access is where long-lived keys survive longest: the AWS job holding a Google service account key, or the Google Cloud workload carrying an Entra client secret. All three providers now let a workload in one cloud present a token from its own platform and exchange it for short-lived credentials in another, but each direction is configured differently and each has its own way of getting the trust conditions wrong. This guide sets out the six directions between AWS, Microsoft Azure and Google Cloud, the source token and target trust for each, the conditions that stop the trust being too broad, and how to roll out and monitor it. It is written for cloud platform, identity and security engineers who own cross-cloud integrations.
Key takeaways
- Every direction is an OIDC-style exchange. The source cloud issues a signed token for the workload; the target cloud trusts that issuer and maps claims (issuer, subject, audience) to a role, managed identity or principal.
- AWS can now be an issuer. IAM outbound identity federation lets AWS principals call GetWebIdentityToken for a short-lived JWT whose subject is the principal ARN, governed by sts:IdentityTokenAudience, sts:DurationSeconds and sts:SigningAlgorithm.
- Trust conditions are the security boundary. A Google provider without an attribute condition, an AWS role without an audience condition, or an Entra app any tenant user can get tokens for opens the target to far more than one workload.
- Exact matching is unforgiving. Entra federated identity credentials must match issuer, subject and audience exactly with no wildcards, allow 20 per app or managed identity, and support RS256-signed issuer tokens.
- Federation does not remove the identity, it moves it. Each trust is a non-human identity relationship that needs an owner, an inventory entry and monitoring in both clouds.
How a cross-cloud exchange works
- Source token: the workload obtains a token from its own platform: an Entra access token for a managed identity, an AWS JWT from GetWebIdentityToken (or signed AWS credentials, for Google's AWS provider), or a Google-issued ID token.
- Target trust: the target has a registered trust for that issuer: an IAM OIDC identity provider and role trust policy in AWS, a federated identity credential (FIC) on an app registration or user-assigned managed identity in Entra, or a workload identity pool provider in Google Cloud.
- Claim checks: the target verifies the signature against the issuer's published keys and checks audience and subject, plus any conditions you added.
- Short-lived credentials: the target returns temporary credentials: AWS STS role session credentials, an Entra access token, or a Google federated token (optionally used to impersonate a service account, one hour by default).
The single-cloud mechanics and the wider rationale are in the Workload Identity Federation Guide; this page is about the cross-cloud combinations.
The six directions
| Source to target | Source token | Target configuration | Key conditions |
|---|---|---|---|
| AWS to Google Cloud | AWS credentials verified with GetCallerIdentity (Google's AWS provider), or an outbound identity federation JWT | Pool provider: gcloud iam workload-identity-pools providers create-aws --account-id | Default mapping google.subject=assertion.arn; attribute condition such as assertion.arn.startsWith('arn:aws:sts::ACCOUNT:assumed-role/') |
| Azure to Google Cloud | Entra access token for a managed identity, audience = Application ID URI | Pool provider: providers create-oidc with --issuer-uri https://sts.windows.net/TENANT_ID and --allowed-audiences set to the App ID URI | google.subject=assertion.sub (the managed identity object ID); restrict the Entra app with app role assignments |
| AWS to Azure | Outbound identity federation JWT; issuer is account-specific, sub is the principal ARN | FIC on a user-assigned managed identity or app registration with that issuer, subject and audience | Recommended audience api://AzureADTokenExchange; exact subject; IAM policy limiting sts:IdentityTokenAudience |
| Google Cloud to Azure | Google-issued ID token for the workload's service account | FIC on a managed identity or app registration | Issuer and subject copied exactly from a decoded sample token; one audience |
| Azure to AWS | Entra access token for a managed identity or app | IAM OIDC identity provider for the Entra issuer, role trust policy for AssumeRoleWithWebIdentity | StringEquals on the provider's aud key and a subject condition; provider and role in the same account |
| Google Cloud to AWS | Google-issued ID token | Role trusting the built-in accounts.google.com provider (AWS says not to create a separate provider for Google) | accounts.google.com:aud condition, plus subject restriction confirmed against the IAM condition key reference |
For the two Google-to-other directions, decode a real token before writing the trust. Microsoft states FIC issuer, subject and audience must match the external token exactly and case-sensitively; Google notes Entra issuer formats can vary, and recommends decoding a token to confirm. Guessing values is the most common reason these exchanges fail or, worse, are written too broadly.
AWS as the source: outbound identity federation
Before outbound identity federation, AWS workloads reaching other clouds relied on the target understanding AWS signatures (as Google's AWS provider does) or on stored keys. With GetWebIdentityToken, AWS STS issues a signed JWT that any OIDC-capable target can verify through AWS's published discovery endpoint.
| Item | Value per AWS documentation |
|---|---|
| IAM action | sts:GetWebIdentityToken; sts:TagGetWebIdentityToken to pass request tags |
| Issuer (iss) | Account-specific, of the form https://<id>.tokens.sts.global.api.aws |
| Subject (sub) | ARN of the requesting IAM principal, for example a role ARN |
| Audience (aud) | Set by the Audience parameter on the request |
| AWS claims | Under https://sts.amazonaws.com/: aws_account, source_region, org_id, ou_path, principal_tags and, when applicable, session context such as ec2_source_instance_arn or lambda_source_function_arn |
| Policy controls | sts:IdentityTokenAudience, sts:DurationSeconds, sts:SigningAlgorithm, aws:RequestTag, aws:TagKeys; SCPs, RCPs and VPC endpoint policies for organisation-wide limits |
- Limit audiences: grant sts:GetWebIdentityToken only with sts:IdentityTokenAudience listing the specific targets, and cap sts:DurationSeconds (AWS's example uses 300 seconds).
- Match the signing algorithm to the target: AWS's examples use ES384, while Microsoft says only RS256-signed issuer tokens are supported for FICs (others may work but are untested). Confirm the algorithm your target accepts and pin it with sts:SigningAlgorithm.
- Use claims for ABAC carefully: principal and request tags appear as claims, which is useful at the target but means whoever can tag the principal or the request can influence them. Restrict tagging with aws:TagKeys.
Getting the target trust right
Google Cloud
- Dedicated project for pools: Google recommends a dedicated project for workload identity pools and providers and a dedicated service account per workload.
- Prefer direct resource access: grant roles directly to the federated principal (principal:// for one subject, principalSet:// for an attribute or group, always with the project number). Use service account impersonation with roles/iam.workloadIdentityUser only where a product does not support federated principals.
- Attribute conditions: without one, any identity the provider accepts can federate. For AWS, restrict to assumed roles in the expected account; for Azure, restrict on the subject.
- Credential configuration file:
gcloud iam workload-identity-pools create-cred-config ... --aws --enable-imdsv2or--azure --app-id-uri. It holds no private key, so it is not a secret, but it does tell an attacker which pool and service account to aim at.
Microsoft Entra ID
- Prefer a user-assigned managed identity where the target resources are Azure resources; use an app registration where you need Microsoft Graph or app roles.
- Plan for limits: 20 FICs per app or managed identity, no wildcards, one audience, issuer and subject up to 600 characters, and a propagation delay that returns AADSTS70021 until the FIC replicates.
- Control who can add FICs: anyone who can add a secret or certificate to an app can add a FIC, which is a quiet way to create a new trust. See the Azure Managed Identities Security Guide.
AWS
- One provider per issuer, one IdP per role: the OIDC provider must be in the same account as the role, and a role trust can name only one federated principal.
- Always condition the trust: AWS requires the role to be limited with a StringEquals condition on the audience; add the subject so only the intended workload qualifies. See the IAM Access Analyzer Guide for reviewing role trust.
- JWKS hygiene: AWS warns that a private key ever published in an issuer's JWKS must be treated as compromised: rotate, review AssumeRoleWithWebIdentity events in CloudTrail and revoke sessions.
Choosing a pattern
| Situation | Pattern | Trade-off |
|---|---|---|
| A few workloads, one direction | Direct federation per workload with exact subject conditions | Simple, but each new workload needs a trust change in the target cloud |
| Many workloads from one source account or tenant | Attribute-based trust (Google principalSet on aws_role, AWS conditions on tags via outbound claims) | Fewer trusts, but tag and role governance in the source cloud becomes part of the target's security |
| Kubernetes workloads in several clouds | Cluster OIDC issuer trusted per target, or a workload identity layer such as SPIFFE | More moving parts; issuer discovery must be reachable by the target |
| Target does not support federation | Short-lived keys issued from a secrets manager with automated rotation | A secret still exists; treat as a temporary exception |
Small organisations usually have a handful of cross-cloud flows and should convert each one from keys to federation directly. Large estates should centralise trust creation through infrastructure as code, with the target cloud's owners approving every new issuer.
Rolling it out
- Inventory (read-only): find cross-cloud static credentials: Google service account keys used outside Google Cloud, Entra client secrets used by AWS or Google workloads, AWS access keys held elsewhere. The Google Cloud Service Account Keys Security Guide covers finding Google keys.
- Build the trust in non-production: create the provider, FIC or role trust with exact conditions, then decode a real source token and compare claims field by field.
- Run side by side: switch the workload to federation while the old key still exists but is unused; confirm in target logs that the federated identity is making the calls.
- Disable the old credential (reversible): disable the Google key or AWS access key and wait a business cycle. Rollback is re-enabling it.
- Delete the old credential (destructive): delete keys and remove client secrets once nothing has failed. Deleted keys cannot be restored.
- Lock in: organisation policies that block new service account keys, Entra app management policies that block new secrets, and SCPs that limit sts:GetWebIdentityToken audiences.
When a step fails, the Multi-Cloud Workload Identity Troubleshooting Guide walks through the failure points.
Detection and measurement
- AWS CloudTrail: GetWebIdentityToken calls (who requested tokens, for which audience) and AssumeRoleWithWebIdentity events for inbound federation; alert on new audiences and new OIDC providers.
- Google Cloud audit logs: token exchanges against the pool and service account impersonation; alert on new providers and on attribute condition changes.
- Entra audit and sign-in logs: FIC additions and changes on apps and managed identities, and service principal sign-ins with federated credentials.
Metrics:
- Cross-cloud flows using static keys versus federation (target: zero static).
- Trusts without an attribute, subject or audience condition (target: zero).
- Federated trusts with a named owner in both clouds.
- Time to remove a trust when the source workload is decommissioned.
- New issuers or FICs created outside the infrastructure-as-code pipeline per month.
Common failure patterns
- Pool provider with no attribute condition: every role in the AWS account, or every identity in the Entra tenant able to get a token for the app, can federate into Google Cloud.
- Entra app open to the whole tenant: Google notes all tenant users can obtain tokens for the application by default; without app role assignments, a user token becomes a route into Google Cloud.
- Binding a session instead of a role: AWS assumed-role ARNs include the session name, so a binding to a single session ARN breaks, and teams "fix" it with a broad condition.
- Old keys left in place: federation works, but the service account key or client secret it replaced is never deleted and remains the easier target.
- Trusts nobody owns: the source workload is retired but the FIC or role trust stays, waiting for anyone who can obtain a matching token. This is the trusted relationship path attackers favour (ATT&CK T1199 Trusted Relationship).
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 Service Identification and Authentication; IA-5 Authenticator Management | Workloads authenticated by federated tokens instead of stored authenticators |
| NIST SP 800-53 Rev 5 | AC-6 Least Privilege; SA-9 External System Services | Scoped trusts and direct resource grants; governance of trusts with external platforms |
| NIST CSF 2.0 | PR.AA-01; PR.AA-05 | Service credentials managed; access permissions reviewed |
| MITRE ATT&CK v20 | T1199 Trusted Relationship; T1550.001 Application Access Token; T1552.005 Cloud Instance Metadata API | Abuse of over-broad trusts, stolen tokens, and metadata-sourced credentials feeding exchanges |
Practitioner checklist
- List every cross-cloud flow and the credential it uses today.
- Decode a real source token and copy issuer, subject and audience exactly into the target trust.
- Add an attribute condition to every Google pool provider and a subject plus audience condition to every AWS role trust.
- Restrict Entra apps used as federation audiences with app role assignments.
- Limit sts:GetWebIdentityToken by audience, duration and signing algorithm, and enforce with SCPs.
- Prefer direct resource access in Google Cloud; impersonate dedicated service accounts only where needed.
- Delete the replaced static keys and secrets after a side-by-side period.
- Record an owner for each trust in both clouds and review trusts quarterly.
- Alert on new providers, FICs and outbound token audiences created outside the pipeline.
Standards and references
- Google Cloud: Configure workload identity federation with AWS or Azure
- Microsoft Learn: Workload identity federation
- Microsoft Learn: Important considerations and restrictions for federated identity credentials
- AWS: IAM outbound identity federation
- AWS: Understanding outbound identity federation token claims
- AWS: Controlling outbound identity federation with IAM policies
- AWS: Create an OpenID Connect identity provider in IAM
- AWS: Create a role for OpenID Connect federation
Related NHI Mgmt Group resources: Workload Identity Federation Guide · Multi-Cloud Workload Identity Troubleshooting Guide · Multi-Cloud Identity Guide · Cloud Workload Identity Guide