🔐AWS → Google Cloud Workload Identity Federation with Terraform

 

Eliminating Service Account Keys for Cross-Cloud Workloads

Managing identities across cloud providers is often more challenging than managing infrastructure.

A common integration pattern is allowing workloads running on Amazon Web Services (AWS) to access Google Cloud resources such as Google Cloud Storage (GCS). The traditional approach typically involves generating long-lived Google service account keys, distributing them to workloads, and rotating them periodically.

This creates several security and operational challenges:

• Long-lived credentials increase the attack surface.
• Secret rotation is often manual and error-prone.
• CI/CD pipelines require secure secret management.
• Compromised keys can provide broad access for extended periods.

Google Cloud Workload Identity Federation (WIF) eliminates these challenges by enabling AWS workloads to exchange trusted identities for short-lived Google access tokens without storing service account keys.

This project demonstrates how to implement AWS → Google Cloud federation using Terraform.

Supported Authentication Patterns

A single Workload Identity Pool supports two authentication paths.

Amazon EKS → Google Cloud Storage

For workloads running inside Amazon EKS, authentication uses projected Kubernetes ServiceAccount tokens.

The EKS cluster's OIDC issuer signs the token, and Google Cloud validates the workload identity through an OIDC provider.

Key characteristics:

• Uses Kubernetes ServiceAccount JWTs
• Preserves pod-level identity
• Supports namespace and ServiceAccount-level authorization
• Does not require AWS IAM credentials inside the pod

EC2 / AWS IAM Role → Google Cloud Storage

For workloads running on EC2 or other compute services that authenticate with AWS IAM roles, authentication uses AWS temporary credentials obtained through AWS STS.

Google Cloud validates the signed AWS request through an AWS workload identity provider and exchanges it for a short-lived Google access token.

Key characteristics:

• Uses AWS STS temporary credentials
• Supports EC2 instances and non-Kubernetes workloads
• Uses IAM role-based authorization
• Eliminates Google service account keys

Architecture Overview

AWS Workload
     │
     ├── EKS Pod → Kubernetes ServiceAccount JWT
     │
     └── EC2 Instance → AWS STS Temporary Credentials
                     │
                     ▼
        Google Cloud Workload Identity Federation
                     │
                     ▼
          Google Service Account Impersonation
                     │
                     ▼
               Google Cloud Storage

Important Design Consideration for Amazon EKS

One of the most common mistakes is attempting to use the AWS IAM provider path from inside EKS pods.

This approach relies on the AWS Instance Metadata Service (IMDS), which returns the IAM role attached to the worker node—not the identity of the pod itself.

As a result, authorization becomes tied to node-level permissions rather than workload identity.

For EKS workloads, the recommended approach is Kubernetes OIDC federation using projected ServiceAccount tokens.

In short:

• EKS pods → Kubernetes OIDC provider
• EC2 instances → AWS IAM provider

Choosing the correct identity source is critical.

What the Repository Includes

• Terraform configuration for Workload Identity Pools and providers
• Amazon EKS OIDC examples
• EC2 and AWS IAM role examples
• Credential configuration generation
• Google Cloud Storage upload examples
• Verification and troubleshooting guidance

Repository:

https://github.com/HenryXiloj/demos-gcp/tree/main/gcp-aws-federation

Benefits of Workload Identity Federation

By adopting Workload Identity Federation, teams can:

• Eliminate long-lived service account keys
• Reduce secret management overhead
• Improve security posture with short-lived credentials
• Simplify credential rotation
• Implement least-privilege access patterns
• Standardize authentication across cloud providers

References

• Kubernetes Workload Identity Federation (EKS): https://docs.cloud.google.com/iam/docs/workload-identity-federation-with-kubernetes
• Workload Identity Federation with AWS and other cloud providers: https://docs.cloud.google.com/iam/docs/workload-identity-federation-with-other-clouds
• Workload Identity Federation overview: https://docs.cloud.google.com/iam/docs/workload-identity-federation
• Google Cloud Storage documentation: https://cloud.google.com/storage/docs

Final Thoughts

Secretless authentication is becoming a foundational requirement for modern cloud platforms.

Workload Identity Federation enables secure, short-lived, and auditable access between cloud providers without the operational burden of managing service account keys.