# Replace stored cloud keys with workload identity > Application engineers frequently rely on long-lived service account keys for cross-cloud authentication, introducing severe credential leakage risks. This article details replacing static keys with Workload Identity Federation, utilizing short-lived tokens governed by precise attribute mapping and conditions. Official source: https://warhoundai.com/blog/cloud-workload-identity/ Published: 2026-11-12 Author: WarHoundAI ## The Risk of Long-Lived Service Account Keys Modern cloud architectures frequently require workloads in one environment, such as AWS or Azure, to interact with resources in another, like Google Cloud Platform. Historically, engineers facilitated this by generating long-lived service account keys and injecting them into the external workload's environment variables or secrets manager. These static credentials present a massive attack surface. If a threat actor gains read access to the workload's environment, they exfiltrate the key and gain persistent access to the target cloud resources until the key is explicitly rotated or revoked. Workload Identity Federation removes the need for stored secrets by establishing a trust relationship between the cloud environments. Instead of relying on a static key, external workloads exchange their environment-specific credentials for short-lived Google Cloud Security Token Service tokens. By utilizing the native identity mechanisms of the compute environment, such as Amazon EC2 instance profiles or Azure virtual machine managed identities, applications seamlessly authenticate without managing credential lifecycles. ## Mechanics of Workload Identity Federation The federation process operates on an exchange mechanism where a workload identity pool acts as the trust boundary. For AWS workloads, Google Cloud supports two primary mechanisms. The first is AWS outbound identity federation, where AWS acts as an OpenID Connect identity provider and issues short-lived JSON Web Tokens to the workloads. The second mechanism uses AWS IAM Credentials, where the workload utilizes its temporary security credentials, and Google Cloud verifies the identity by making a call to the AWS GetCallerIdentity API. New Amazon EC2 instances default to IMDSv2, requiring workloads to execute authentication requests accordingly. For Azure workloads, the process relies on Microsoft Entra ID. Administrators register a new application within their tenant and assign an Application ID URI. Azure virtual machines utilize managed identities to request access tokens from the Azure Instance Metadata Service for this registered application. Google Cloud then validates the signature and claims of the Entra ID token against the configured workload identity pool provider, exchanging it for Google Cloud access. ## Attribute Mapping and Access Control Conditions Mapping assertions from the external identity provider to Google Cloud attributes is the foundation of authorization. The google.subject attribute acts as the primary identifier in Cloud Audit Logs. When federating AWS IAM credentials via GetCallerIdentity, available source attributes include account, arn, and userid. Engineers typically map google.subject directly to assertion.arn. Additionally, custom attributes can extract granular context. A common pattern is defining attribute.aws_role by applying the extract function to the ARN, isolating the assumed role name. Azure token mapping typically relies on the sub claim for google.subject. If the sub claim exceeds the 127-character limit for the subject attribute, the extract function must be used to derive a compliant identifier. To prevent lateral movement, administrators must deploy attribute conditions. These Common Expression Language rules evaluate the incoming assertions before granting a token. A strong condition for AWS might assert that assertion.arn.startsWith matches a specific expected account and role path, immediately rejecting unexpected principals. ## Concrete Worked Example: AWS EC2 to Cloud Storage Consider a synthetic fixture where an application running on AWS EC2 requires read access to a Google Cloud Storage bucket named production-assets-bucket. The AWS workload assumes an IAM role named data-processor-role in AWS account 123456789012. The engineer creates a workload identity pool named aws-compute-pool and a provider named aws-processor-provider. The attribute mapping is configured as google.subject=assertion.arn and attribute.aws_role=assertion.arn.extract('assumed-role/{role_name}/'). The attribute condition is set to assertion.arn.startsWith('arn:aws:sts::123456789012:assumed-role/data-processor-role/'). Finally, the engineer grants the roles/storage.objectViewer IAM role directly on the production-assets-bucket using the principalSet identifier: principalSet://iam.googleapis.com/projects/987654321098/locations/global/workloadIdentityPools/aws-compute-pool/attribute.aws_role/data-processor-role. ## Safe Test Matrix with Expected Outcomes Validating the federation configuration requires systematic testing of allowed and denied assertions. Test Case 1: Workload assumes data-processor-role in AWS account 123456789012. Expected outcome: Allowed. The ARN matches the attribute condition, and the extracted aws_role matches the principalSet binding on the bucket. Test Case 2: Workload assumes backup-role in AWS account 123456789012. Expected outcome: Denied. The ARN fails the attribute condition restricting access to data-processor-role. The token exchange is rejected by the Security Token Service. Test Case 3: Workload assumes data-processor-role in unauthorized AWS account 999999999999. Expected outcome: Denied. The ARN fails the attribute condition checking the 123456789012 account prefix. Test Case 4: Request originates from Azure with matching Entra ID role name. Expected outcome: Denied. The Azure request hits a different provider or fails the provider's inherent issuer validation, never reaching the AWS-specific attribute evaluation. ## Implementation Tradeoffs and Failure Modes Transitioning to Workload Identity Federation introduces operational complexity. The primary tradeoff is the requirement for active compute environments to negotiate tokens dynamically, which adds latency to the initial API call compared to presenting a static key. Failure modes often stem from identity metadata service availability or network egress restrictions that prevent the workload from reaching the Google Cloud STS endpoints. Configuration drift is another risk. If the external cloud team renames an IAM role or modifies a managed identity structure without updating the Google Cloud attribute mapping or conditions, authentication will silently fail. Furthermore, complex CEL expressions in attribute conditions are notoriously difficult to debug locally. Engineers must rely heavily on Cloud Audit Logs to diagnose why a specific token exchange request evaluated to false. ## Sources Google Cloud Identity and Access Management: Configure Workload Identity Federation with AWS or Azure VMs Drafted with Gemini and checked for source links, advisory identifiers, structure and unsupported product claims. Examples are synthetic and are not scan results. Drafted with Gemini and checked for source links, advisory identifiers, structure and unsupported product claims. Examples are synthetic and are not scan results. - [Configure Workload Identity Federation with AWS or Azure VMs](https://docs.cloud.google.com/iam/docs/workload-identity-federation-with-other-clouds) - [Primary reference: cloud.google.com](https://cloud.google.com/iam/docs/workload-identity-federation-with-other-clouds)