The Evolution of Cross-Cloud Workload Identity Federation

Running distributed services across multiple cloud providers has historically forced infrastructure teams into fragile credential pipelines. A pod in an Elastic Kubernetes Service cluster that needed to query BigQuery or write objects to Google Cloud Storage usually depended on long-lived service account keys, external secret vaults, or custom sidecar proxies. Over the past eight years, cross-cloud workload identity evolved from manual JSON files into automated, standards-based federation.

2018 – Static service account keys and secret rotation bots

Eight years ago, granting an AWS workload access to GCP resources meant creating an IAM service account in GCP, generating a private key file, and mounting that JSON blob into an EKS pod as a Kubernetes Secret. Security teams wrote cron jobs and bash scripts to rotate these keys every ninety days. When rotation scripts failed, production services broke; when scripts succeeded without incident, unencrypted keys still sat inside cluster etcd storage and developer laptops. A leaked key provided indefinite access until an administrator revoked the credential in the Google Cloud console.

2020 – OIDC discovery and native cloud federation

Cloud providers began embracing OpenID Connect federation around 2020. AWS introduced IAM Roles for Service Accounts (IRSA), while GCP launched Workload Identity Federation. Instead of parsing static JSON secrets, Kubernetes clusters exposed an OIDC discovery endpoint (/.well-known/openid-configuration) and published public keys via JSON Web Key Sets (JWKS). Pods projected short-lived JSON Web Tokens signed by the Kubernetes API server directly into the container filesystem:

apiVersion: v1
kind: Pod
metadata:
  name: storage-sync
  namespace: data-pipeline
spec:
  serviceAccountName: gcp-sync-sa
  containers:
  - name: sync-worker
    image: data-worker:v2.1
    volumeMounts:
    - mountPath: /var/run/secrets/tokens
      name: projected-token
  volumes:
  - name: projected-token
    projected:
      sources:
      - serviceAccountToken:
          path: oidc-token
          expirationSeconds: 3600
          audience: "https://iam.googleapis.com/projects/123456789/locations/global/workloadIdentityPools/aws-pool/providers/k8s-provider"

This shifted the threat boundary away from disk persistence, but platform teams still had to manually define Workload Identity Pools, configure provider trust relationships, and map IAM bindings in Terraform across both cloud accounts for every new microservice.

2022 – SPIFFE/SPIRE and multi-cluster mesh identities

By 2022, large deployments adopted the SPIFFE standard and SPIRE runtime agents to decouple workload identity from any single cloud vendor. By deploying SPIRE server instances alongside Kubernetes, teams issued cryptographic X.509 SVIDs and JWT-SVIDs to applications regardless of host platform. While SPIFFE solved mutual TLS and cross-cluster verification inside private networks, bridging those identities into proprietary cloud control planes still required translation proxies or custom token-exchange brokers running on edge nodes.

2024 – Kubernetes operators managing identity sync

Two years ago, the ecosystem shifted toward declarative Kubernetes operators. Instead of managing cross-cloud trust out-of-band in cloud consoles, operators treated native Kubernetes ServiceAccounts as the primary authority. Creating a ServiceAccount inside a cluster automatically provisioned corresponding IAM roles in AWS and GCP via the provider management APIs. The operator reconciled cluster state against cloud trust stores continuously, eliminating configuration drift and manual IAM mapping.

Static credentials are an architectural defect in distributed systems. When identity stems directly from the orchestrator runtime, security boundaries become verifiable rather than procedural.

Where we are now

Today, projects such as myceliam implement bidirectional workload identity federation across clouds entirely within Kubernetes custom resource definitions. Modern operators reconcile Kubernetes namespaces, establish cloud OIDC provider trust automatically, and handle token exchange through native Security Token Service (STS) endpoints without writing temporary tokens to persistent storage. Inspecting trust pools and validating active token exchange can be performed directly through standard CLI tooling:

# Exchange projected Kubernetes JWT for short-lived GCP access token
gcloud auth print-access-token \
  --credential-configuration-file=/etc/workload-identity/gcp-config.json

# Verify the caller identity recognized by Google Cloud IAM
curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  https://cloudresourcemanager.googleapis.com/v1/projects/my-prod-project

Eliminating static secrets across cloud boundaries is no longer an enterprise luxury. By anchoring authentication to OIDC discovery documents and orchestrator-level controllers, cross-cloud infrastructure operates with zero shared keys, automated token expiry, and clear audit trails across every cloud provider.