Multi-Cloud Identity Without Secrets: AWS ↔ GCP Federation

Modern cloud architectures often require workloads in one cloud to access services in another. Instead of storing long-lived credentials (API keys or service account keys), we can use identity federation. This allows a workload to prove its identity and receive temporary credentials.

This article explains two common scenarios in a simple way.

---

Scenario 1: AWS EC2 Accessing GCP Cloud Storage

Problem

An application running on an AWS EC2 instance needs to read or write data in GCP Cloud Storage.

Storing a GCP service account key on EC2 is insecure.

Solution

Use Workload Identity Federation in GCP to trust the AWS identity.

Architecture

AWS EC2 ↓ IAM Role attached to EC2 ↓ Identity verified by GCP ↓ GCP Workload Identity Federation ↓ Temporary GCP Service Account Token ↓ Access Cloud Storage

Steps

1. AWS Side

Create an IAM Role and attach it to the EC2 instance.

Example role:

EC2-GCP-Federation-Role

This role only identifies the EC2 instance. It does not need GCP permissions.

---

1. GCP Side

Create:

• Workload Identity Pool

• AWS Provider

• Service Account

Example service account:

ec2-storage-access@project.iam.gserviceaccount.com

---

1. Grant Storage Permissions

Assign permissions to the service account:

roles/storage.objectViewer

or

roles/storage.objectAdmin

---

1. Allow AWS Role to Impersonate Service Account

Bind the AWS role to the GCP service account using the role:

roles/iam.workloadIdentityUser

---

Runtime Flow

1. EC2 instance uses its IAM role.

2. GCP verifies the AWS identity.

3. GCP issues a temporary service account token.

4. Application accesses Cloud Storage.

No credentials are stored on EC2.

---

Scenario 2: GCP VM Accessing AWS Cognito

Problem

A workload running on a GCP VM needs to call AWS APIs such as Cognito.

Storing AWS access keys on the VM is insecure.

Solution

Use OIDC federation with AWS STS so AWS trusts the GCP identity.

Architecture

GCP VM ↓ GCP Service Account ↓ OIDC Identity Token ↓ AWS STS AssumeRoleWithWebIdentity ↓ Temporary IAM Role Credentials ↓ Access AWS Cognito

---

Steps

1. GCP Side

Create a service account and attach it to the VM.

Example:

gcp-vm-sa@project.iam.gserviceaccount.com

The VM can generate an identity token from the metadata server.

No special IAM roles are required.

---

1. AWS Side

Create:

• OIDC Identity Provider (issuer: Google)

• IAM Role

Example role:

GCPFederatedAccessRole

---

1. Trust Policy

Allow the Google identity to assume the role.

Example condition:

accounts.google.com:sub = gcp-vm-sa@project.iam.gserviceaccount.com

---

1. Attach Permissions

Attach policies to the IAM role to allow Cognito access.

Example permissions:

cognito-idp:ListUsers cognito-idp:AdminGetUser

---

Runtime Flow

1. GCP VM generates an identity token.

2. Token is sent to AWS STS.

3. AWS verifies the identity.

4. Temporary IAM credentials are issued.

5. Application calls Cognito APIs.

Again, no static credentials are stored.

---

Key Takeaway

In cross-cloud access:

Source Cloud → proves identity Target Cloud → grants permissions

AWS → GCP example EC2 IAM Role proves identity, while GCP service account permissions control storage access.

GCP → AWS example GCP service account proves identity, while AWS IAM role permissions control Cognito access.

---

Why This Matters

Benefits of identity federation:

• No long-lived credentials

• Short-lived tokens

• Better security

• Ideal for multi-cloud architectures

As multi-cloud adoption grows, federated identity is becoming the standard way for workloads to authenticate across cloud providers.