Workload federation across clouds needs separate trust decisions

The identity changes at every exchange

Workload federation across clouds needs separate decisions about source identity, accepted proof, target credentials and resource permission. A runtime identity that is meaningful in one provider does not carry a portable authorization policy into another. Map each exchange and the owner of each grant before removing a stored credential. The useful result is an explicit chain of trust and access decisions, not a diagram that connects two cloud logos with a single arrow. ^[1][2][6]

This guide focuses on running workloads rather than a CI deployment walkthrough. A service on one cloud may need to read a resource on another while its source platform supplies an ambient identity. Federation can replace a separately distributed target credential in a supported design. The runtime still needs a secure source identity, a trustworthy credential configuration, supported token exchange and narrowly scoped permission at the destination. Each of those requirements can fail independently. ^[2][3][4]

Consider a hypothetical service on an AWS virtual machine that needs to read one approved Google Cloud resource. The source environment identifies the workload through an AWS role. Google Cloud accepts a configured form of source proof and maps it into a federated identity. The application may access the resource directly where supported or use an explicitly authorized service-account impersonation step. The example does not assume that accepting the AWS identity automatically grants the Google resource operation. ^[2][4]

A second direction can use a different mechanism. An external workload seeking an Entra access token needs a federated credential relationship whose issuer, subject and audience match the supported external-token contract. An AWS web-identity role session follows the AssumeRoleWithWebIdentity API and the selected role's trust and permission rules. These integrations share federation concepts but not one universal request format or one set of matching semantics. ^[1][6][8]

RFC 8693 supplies token-exchange terminology, including distinctions between the identity represented by a token and another actor in a delegated operation. It is useful for describing the chain, but it does not prove that every provider implements every exchange option or accepts another provider's token unchanged. Keep the concrete vendor API alongside the conceptual model. A standards vocabulary should make differences clearer, not conceal unsupported interoperability assumptions. ^[9]

The first deliverable should be a hop record: source environment, proof type, issuer or authority, accepted subject, audience, exchange endpoint, optional impersonation and final resource grant. Add owners and evidence for each transition. This record exposes where a workload can obtain credentials but still lacks permission, and where a broad trust configuration could accept more source identities than the resource owner intended.

Establish what the source environment can prove

Identify the actual source credential mechanism before choosing a target configuration. Google Cloud's current AWS and Azure VM guidance describes environment-specific credentials, including AWS instance-profile credentials and Azure managed-identity access tokens. These mechanisms have different formats and provenance. Do not describe all ambient workload identity as an OIDC JWT merely because the destination supports federation. The source environment determines what proof the workload can obtain. ^[4]

The same Google guide now distinguishes two AWS approaches. One uses AWS IAM credentials, with identity verification through GetCallerIdentity. The other uses AWS outbound identity federation, in which AWS issues OIDC JWTs for external services. The remaining AWS IAM-credential instructions in that guide apply to that mechanism, not automatically to the outbound OIDC route. Select the intended integration explicitly and use its matching credential configuration. ^[4]

AWS's own outbound federation guide describes account enablement, an account-specific issuer and permissions to call GetWebIdentityToken. It also states that the operation is not available on the STS Global endpoint and that the generated outbound JWTs cannot be used for inbound AWS federation through AssumeRoleWithWebIdentity. This is a concrete limit on treating federation as bidirectional token portability. The identity can be represented for a supported external trust relationship without becoming a credential accepted by every AWS or non-AWS endpoint. ^[11]

For Azure VM federation into Google Cloud, review which identities can obtain a token for the configured Entra application and which claims identify the intended workload. Google's guidance warns that default application settings can allow a broader tenant population to obtain tokens and describes restricting the permitted identities. The target trust review therefore needs source issuance scope as well as target claim matching. A validly issued token is not necessarily a token from the one workload the application owner meant to authorize. ^[4]

Examine the lifetime and availability of the source credential separately from the target token. The runtime may need a metadata service, an identity endpoint or another supported source mechanism to refresh proof. Existing target credentials can temporarily conceal a broken source path. The architecture should identify that dependency and test it in the actual workload environment, without assuming that a developer's interactive credentials represent the deployed service.

Protect the configuration that tells a library where to obtain source credentials. Google explicitly discusses risks from malicious credential configurations and recommends validating configurations obtained from an external source. A configuration file is not harmless merely because it contains no long-lived private key. It can direct credential acquisition or token exchange behavior. Treat its provenance, permitted endpoints and deployment ownership as part of the trust boundary. ^[3]

Keep local testing identities separate from runtime evidence. A command run by an administrator may succeed through the administrator's account while the deployed workload uses another identity path. Record the principal and credential mechanism exercised by each test, using non-secret identifiers. A successful local request is useful diagnostic evidence, but it does not prove that the runtime's ambient identity, network path and refresh mechanism are correctly configured.

Write a target-specific trust contract

The target must decide which source authority and claims it accepts. In an OIDC-style integration, issuer, subject and audience are central inputs, but their exact interpretation belongs to the target's documented contract. The issuer identifies the authority that produced the assertion. The subject identifies the represented source entity. The audience identifies the intended recipient. None of those fields alone supplies the target resource's full permission policy. ^[6][8][9]

Entra's federated identity credential overview describes matching the configured issuer, subject and audience with the incoming external token, including case-sensitive matching. Preserve those values exactly where the supported credential model requires it. A display name or a visually similar string is not a substitute for the documented claim. Microsoft also notes that a credential configuration can be created successfully even when the supplied subject information will later fail at token exchange. Configuration creation and working authentication are different acceptance events. ^[7][8]

Use current platform restrictions rather than assuming every standards-compliant token is supported. Microsoft's considerations page documents signing-algorithm and issuer requirements for its federation mechanism. AWS outbound federation can emit supported signing options, but the receiving service determines which it accepts. Select a compatible path from the current documentation for both ends and test it. Do not copy a provider's general preference for an algorithm into a target that has a narrower supported contract. ^[7][11]

Google Cloud adds attribute mapping and conditions to its federation configuration. The mapping determines how source attributes become the federated subject or other attributes used in access decisions. Conditions can restrict which credentials are accepted. Review both the mapping and the condition, because a broadly mapped identity can remain broader than intended even when a resource grant looks narrowly named. The best-practice guidance emphasizes tenant and identity restrictions for shared issuers. ^[2][3][4]

Choose identifiers that preserve the intended identity boundary. A mutable name, reused label or incomplete source identifier can make an access rule apply differently after an organizational change. Google's guidance recommends care with subject mappings and identifiers that can be reassigned. Record the source of each claim, who can change it and whether the target policy relies on it for identity or merely for descriptive context. A convenient label is not automatically a durable security principal. ^[3][4]

For an AWS web-identity role, inspect the selected role's trust relationship and the conditions governing the accepted identity provider and token. The API's ability to return temporary credentials does not establish that the trust policy is narrow enough. The role owner should be able to explain why the intended issuer, subject and audience combination is accepted and why a different workload under the same broad provider is rejected. ^[1]

Test substitutions that challenge the chosen trust boundary. A token from the wrong source tenant, an unexpected workload subject or an unintended audience should receive the documented rejection. Use controlled identities and approved test configurations, not tokens taken from unrelated users. Keep the denied exchange separate from a denied resource request: the first tests identity acceptance, while the second tests permission after credential issuance.

The illustrated token card separates identity claims from the resource-policy card for this reason. It is a conceptual model with no realistic token string or private credential. An issuer can establish who presented a claim, while the destination still needs an explicit grant for the operation. The design should never rely on the appearance of a well-formed token as evidence that every downstream access decision has already been made.

Source. Graph federated identity credential overview ^[8]; RFC 8693 OAuth token exchange ^[9]; Microsoft access tokens ^[10]. Sources checked August 28, 2026.

Method. Original conceptual model synthesized from the cited documentation. The relationships and proposed tests explain design choices; they are not measured results or a claim about a deployed environment.

Accessible table and figure data

Figure 1 accessible table

Field or record	Question it helps answer	What it does not grant
Issuer	Who issued this assertion?	Trust in every assertion from that issuer
Subject	Which source identity is represented?	Permission to every target resource
Audience	Which recipient is intended?	A portable permission set
Expiration	When does this token stop being valid?	Immediate termination of every derived session
Target grant	Which operations may this identity perform here?	Authority in another cloud

Figure 1 accessible table

Field or record	Question it helps answer	What it does not grant
Issuer	Who issued this assertion?	Trust in every assertion from that issuer
Subject	Which source identity is represented?	Permission to every target resource
Audience	Which recipient is intended?	A portable permission set
Expiration	When does this token stop being valid?	Immediate termination of every derived session
Target grant	Which operations may this identity perform here?	Authority in another cloud

Download imageDownload table CSV

Choose direct access or a deliberate impersonation hop

Google Workload Identity Federation supports direct resource access by a federated principal where the relevant service and identity type support it. It also supports a service-account impersonation approach. These are different authorization paths. Choose the supported path deliberately and document why an additional identity hop is needed, rather than adding impersonation automatically to every integration because a sample configuration includes it. ^[2]

With direct access, the resource policy identifies the accepted federated principal or principal set under the platform's supported syntax. The source-to-target mapping and the resource grant must agree on what that identity represents. An overly broad principal set can make a carefully configured source identity less useful as a boundary. Review the resource operation and scope alongside the federation mapping, not in a separate document that assumes the mapping was already safe. ^[2][3]

With service-account impersonation, the federated identity first needs authority to obtain credentials for the selected service account. The service account then needs permission on the final resource. Those grants answer different questions and should have separate owners or review evidence. A successful impersonation request proves that the intermediate credential could be issued; it does not prove that the resulting identity has the correct resource permission or that every other service account is protected from the caller. ^[2][5]

Keep delegation details in the appropriate implementation record. Google's generateAccessToken API documents the request and delegation chain semantics. If a design uses more than one service-account hop, each step needs the required authority under that contract. This pillar does not repeat the separate impersonation-hop implementation guide. Its contribution is to make the additional authority transition visible in the cross-cloud architecture and acceptance record. ^[5]

For AWS, temporary role credentials are governed by the role and applicable session and resource policy evaluation. The AssumeRoleWithWebIdentity API describes how session policies can restrict the permissions of the resulting session and cannot grant beyond the role's identity-based permissions. Do not summarize the entire effective access decision as a property of the source token. The target role and resource controls remain part of the authorization system. ^[1]

For Entra, the resulting access token is intended for a particular resource, and the resource owns the token's interpretation. The Microsoft identity platform documentation distinguishes clients that request tokens from APIs that accept and validate them. A workload client should use the supported library and resource contract instead of assuming every access token is a JWT it should parse and reinterpret for its own policy. Accepted external proof and accepted resource access are different stages. ^[6][10]

Test the final operation at the intended scope. A workload meant to read one resource should not be accepted merely because it can obtain a token or enumerate unrelated account metadata. Perform a permitted representative operation and a controlled out-of-scope operation, recording the expected allowed and denied outcomes separately. This connects the architecture to a concrete resource boundary without granting broad permissions just to make an initial integration test pass.

Source. AWS AssumeRoleWithWebIdentity ^[1]; Google Workload Identity Federation ^[2]; Google federation from AWS and Azure VMs ^[4]; Microsoft workload identity federation ^[6]; RFC 8693 OAuth token exchange ^[9]. Sources checked August 28, 2026.

Method. Original conceptual model synthesized from the cited documentation. The relationships and proposed tests explain design choices; they are not measured results or a claim about a deployed environment.

Accessible table and figure data

Figure 2 accessible table

Stage	Presented evidence	Decision owner	What remains separate
Source runtime	Ambient identity under source rules	Source identity service	Target access
External assertion	Issuer, subject and audience	Target federation configuration	Resource permission
Token exchange	Accepted subject proof and exchange request	Target token service	Optional impersonation permission
Optional impersonation	Authorized identity and target account	Service-account policy owner	Final resource authorization
Resource request	Target credential and requested operation	Resource policy owner	Runtime recovery and refresh

Figure 2 accessible table

Stage	Presented evidence	Decision owner	What remains separate
Source runtime	Ambient identity under source rules	Source identity service	Target access
External assertion	Issuer, subject and audience	Target federation configuration	Resource permission
Token exchange	Accepted subject proof and exchange request	Target token service	Optional impersonation permission
Optional impersonation	Authorized identity and target account	Service-account policy owner	Final resource authorization
Resource request	Target credential and requested operation	Resource policy owner	Runtime recovery and refresh

Download imageDownload table CSV

Keep the credential clocks separate

A federated workload can encounter several expiration times: source credentials, an external assertion, an exchanged token and an optional impersonated credential. Those clocks do not necessarily begin together or share a maximum. Label the credential stage whenever discussing lifetime. Otherwise, a team can mistake a short source assertion for proof that a previously issued target credential has the same remaining lifetime.

AWS AssumeRoleWithWebIdentity accepts a requested DurationSeconds from 900 seconds up to the selected role's configured maximum session duration. The default is 3,600 seconds, and a role's maximum can be configured up to 43,200 seconds. In the chart these become 15, 60 and 720 minutes. The 720-minute row is conditional on the role configuration, not a guarantee that every role accepts a 12-hour request. ^[1]

Google's generateAccessToken API concerns a service-account access token, which is a later stage when the design uses impersonation. Its default lifetime and ordinary maximum are one hour. An organization policy allowing the relevant service account under the documented lifetime-extension constraint permits up to 12 hours. The chart shows these as 60 and 720 minutes while preserving which value is a default, an ordinary maximum or a policy-enabled extension. ^[5]

Entra's general access-token documentation describes default lifetime variation between 60 and 90 minutes, with resource and policy exceptions. Those values are a documented default range, not the universal minimum and maximum for every Entra token. The chart therefore places them in a separate panel with explicit labels. Do not compare that range directly with a configurable AWS role ceiling as if they were equivalent security settings. ^[10]

AWS outbound GetWebIdentityToken introduces another source-token stage with its own documented contract. It is intentionally excluded from the target-credential chart. The same exclusion applies to the initial Google STS exchange when the chart discusses a later generated service-account token. A single plot of unlabeled cloud token lifetimes would conceal these differences; the figure retains each credential and setting together and makes no provider ranking. ^[4][5][11]

Expiration is also different from revocation or permission change. Removing source issuance, changing target trust and withdrawing resource authority affect different decisions. Do not promise that disabling one upstream path immediately invalidates every credential already issued downstream. The incident procedure should identify which new exchanges are prevented, which issued credentials remain relevant and which resource controls are available, using the provider-specific behavior rather than an inferred universal window.

Use supported SDK and API expiration information for refresh. Avoid building operational logic around assumptions about a token's internal format or copying raw tokens into logs to inspect their clocks. Microsoft's documentation explicitly treats resource ownership and client token handling as separate concerns. The workload's evidence record should identify the credential stage, expiry information and refresh outcome without turning observability into another credential-distribution channel. ^[10]

Source. AWS AssumeRoleWithWebIdentity ^[1]; Google generateAccessToken ^[5]; Microsoft access tokens ^[10]. Sources checked August 28, 2026. Documented target-credential settings checked August 28, 2026, shown in minutes. AWS values describe AssumeRoleWithWebIdentity sessions, Google values describe generated service-account access tokens, and Entra values describe its general default variation. They are different service contracts, not equivalent security guarantees or revocation SLAs.

Method. Original faceted plot of AWS DurationSeconds, Google's generateAccessToken lifetime and Microsoft's access-token lifetime documentation. AWS seconds and Google hours were converted to minutes. Each panel retains its own default, limit or range semantics. Resource and policy exceptions exist in Entra; the default range is not universal for every resource or client. Disabling source identity, removing trust and changing target permissions have separate effects from expiry. Access tokens already issued may outlive an upstream credential or trust change. Do not combine these rows into an average or cross-cloud maximum.

Accessible table and figure data

Figure 3 accessible table

Credential	Setting	Minutes	Meaning
AWS web identity role session	Requested minimum	15	DurationSeconds minimum
AWS web identity role session	Default	60	Default DurationSeconds
AWS web identity role session	Role-configurable ceiling	720	Only if the role maximum allows it
Google service-account access token	Default	60	Unspecified lifetime
Google service-account access token	Ordinary maximum	60	Without allowed lifetime extension
Google service-account access token	Policy-enabled maximum	720	Allowed service account in lifetime-extension policy
Microsoft Entra access token	General default range start	60	Lower end of documented default variation
Microsoft Entra access token	General default range end	90	Upper end of documented default variation

Figure 3 accessible table

Credential	Setting	Minutes	Meaning
AWS web identity role session	Requested minimum	15	DurationSeconds minimum
AWS web identity role session	Default	60	Default DurationSeconds
AWS web identity role session	Role-configurable ceiling	720	Only if the role maximum allows it
Google service-account access token	Default	60	Unspecified lifetime
Google service-account access token	Ordinary maximum	60	Without allowed lifetime extension
Google service-account access token	Policy-enabled maximum	720	Allowed service account in lifetime-extension policy
Microsoft Entra access token	General default range start	60	Lower end of documented default variation
Microsoft Entra access token	General default range end	90	Upper end of documented default variation

Download imageDownload table CSV

Refresh and failure belong in the application design

The initial successful exchange is only the beginning of runtime acceptance. The workload needs to refresh credentials through the same supported source and target path while it remains deployed. Test that path after the initial credential has been replaced, using controlled conditions appropriate to the library. An application can appear healthy while cached target credentials conceal a broken source identity or an inaccessible exchange endpoint. ^[3][4]

Use a supported credential library and validate its configuration for the actual environment. The library may obtain source proof, exchange it and refresh derived credentials, but the application still owns how failures are reported and handled. Record the version and configuration source. A configuration demonstrated in a developer shell is not automatically the configuration packaged with the service, scheduled worker or recovery deployment. ^[3][4]

Plan for propagation after trust changes. Microsoft's federation considerations document that newly configured credentials can take time to propagate and that token requests may temporarily fail against older cached configuration. That behavior should inform a controlled rollout and bounded retry strategy. It should not become a reason to broaden the subject or audience match when the actual problem is propagation, or to claim that a newly created configuration is already proven everywhere. ^[7]

Distinguish transient failure from an authorization mismatch. A retry may be appropriate for documented temporary conditions, but repeatedly requesting a token with the wrong issuer or subject does not repair the trust contract. Preserve the failure category and relevant non-secret identifiers before changing settings. A troubleshooting procedure should narrow the failed boundary rather than replace several controls at once until the request happens to succeed.

Map the availability dependencies of refresh. The source credential service, target exchange endpoint, optional impersonation service and final resource can each be unavailable or unreachable. The workload may need a defined response when it can no longer obtain an authorized credential. Choose that response from the application's requirements and the supported library behavior, without inventing a universal cached-credential grace period or fallback identity.

Do not add an undocumented static credential as an automatic fallback. Such a path can remain in use after the federation problem is fixed, conceal a failed trust configuration or carry different permissions. If the organization deliberately retains a recovery credential during migration, document its scope, owner, permitted invocation and removal condition. The existence of that exception means the workload has more than one authentication path, and acceptance should account for both.

Observe refresh without retaining reusable proof. Logs can record the source identity class, target provider, configuration version, stage and outcome where supported. They should not contain complete assertions, access tokens or private source credentials. The operational question is which boundary failed and which path was used, not whether an operator can reconstruct a working credential from the troubleshooting record.

Test identity substitutions and resource denial

Create an authorized test plan that follows the hop record. Start with the intended runtime identity and a narrowly scoped target operation. Record the source environment, credential mechanism, trust configuration and resource grant under test. Use synthetic or otherwise permitted data. The article's examples are proposed acceptance procedures and do not claim that a real tenant or account configuration has been exercised.

Prove the source path first. Confirm that the workload obtains proof through the intended ambient identity rather than a developer account, inherited environment secret or another credential source. This matters when a library supports several authentication mechanisms. A successful request through an unintended fallback can conceal the fact that the deployed federation configuration was never used. ^[3][4]

Then test exchange acceptance and rejection. The intended source identity should obtain the expected target credential under the supported contract. Controlled substitutions in issuer, subject, audience or another required attribute should be rejected at the relevant boundary. Record which field and configuration rule produced the decision. Do not use a token from an unrelated real user as a convenient negative fixture. ^[1][3][8]

If the design includes impersonation, test that hop independently. Confirm the intended service account is accessible under the approved grant and that an out-of-scope account is not. Then perform the final permitted resource operation and a controlled denied operation. Keeping these observations separate helps distinguish an impersonation-policy gap from an overly broad resource grant or a failure to match the external identity. ^[2][5]

Exercise refresh and a supported failure condition after initial success. For example, a controlled test can establish whether the workload reports a rejected exchange clearly when its test trust configuration no longer matches. The exact mutation and cleanup need authorization and should remain isolated from production access. Record whether already issued credentials were involved so the test does not mistake cached success for continued acceptance of new proof.

Test deployment diversity. A long-running service, an infrequent job and a recovery environment may load different credential configurations or use different SDK versions. The inventory should identify which classes were exercised and which remain untested. A single canary proves its own path unless there is defensible evidence that the other instances use the same relevant configuration and behavior.

Preserve the distinction between proposed expectations and observed results. The sequence diagram describes where decisions occur; it is not a trace from a real request. The chart describes published credential settings; it is not a measured revocation or refresh result. A release record should attach actual observations to the same boundaries without turning the explanatory visuals into fabricated operational evidence.

Before removing an old stored credential, confirm that the deployed workload uses the intended federated path and that the fallback or recovery arrangement is understood. The separate static-key-removal guide owns the retirement procedure. Here, the acceptance gate is the identity and permission chain: the intended source proof is accepted, inappropriate proof is rejected and the final resource grant is no broader than required.

A handoff record that survives the next cloud move

Keep the completed hop record with the workload's operational documentation. It should name the source identity mechanism, target trust fields, optional impersonation, resource grant, credential stages, refresh behavior and evidence owners. Include the actual source-review date and the versions used in testing. A future operator should be able to locate the failed boundary without rediscovering why the workload was allowed to cross providers.

Review the record when the runtime, issuer, subject mapping, credential library or resource scope changes. A workload moved to another environment can retain the same application name while presenting a different identity or relying on a different credential source. The target trust policy needs to be evaluated against that new proof. Federation should make the relationship explicit, not encourage treating a familiar workload label as permanent authorization. ^[3][9]

Keep configuration provenance visible during those changes. Credential files, trust policies and resource grants can be maintained by different teams and deployment systems. Record the approved source for each and the review required before accepting an external configuration. Google's guidance on malicious credential configuration is a reminder that keyless does not mean configuration-free or trust-free. ^[3]

The final operational claim should be modest and precise. The organization has verified a particular source identity, exchange mechanism and resource permission under a defined configuration, with stated refresh and recovery behavior. It has not created a universal credential accepted across every cloud, and it has not eliminated the need to govern tokens already issued.

That precision is the practical benefit of a separate trust decision at every hop. It lets a runtime obtain supported short-lived credentials while keeping source issuance, target identity acceptance and resource authority understandable. When the workload moves or a provider changes its contract, the organization can update the affected relationship instead of guessing which part of a broad federation label stopped being true.