Federated Workload Identity Across Clouds
Defakto
The real gap is not identity issuance inside one cloud, it is carrying the same workload identity and policy model across AWS, Azure, and Google Cloud without rewriting trust for each platform. AWS IRSA ties a Kubernetes service account to an IAM role inside EKS, Microsoft Entra Workload ID is built around app and service identities in the Entra stack, and Google Workload Identity Federation is designed to grant access into Google Cloud from external environments. Each works well for its own control plane, but none acts as a neutral federation layer across all three.
-
In practice, single cloud identity means platform teams set up separate trust paths per cloud. One pod talking to S3, Azure Key Vault, and Google Cloud Storage may need different identity bindings, token exchanges, and policy objects in each environment, which creates operational sprawl as companies go multi-cloud.
-
Google explicitly positions Workload Identity Federation for workloads running on AWS, Azure, on premises systems, GitHub, GitLab, and other OIDC or SAML providers. That is federation into Google Cloud, not a shared cross-cloud identity control plane, so the center of gravity still remains with one hyperscaler.
-
This is why vendors like CyberArk, through Workload Identity Manager, and Defakto are moving up from certificate tooling into workload identity platforms. The value is not just issuing short lived credentials, it is giving security teams one trust system and one policy layer for workloads that move across hybrid and multi-cloud estates.
The market is heading toward identity systems that sit above any one cloud and translate a workload's identity into whatever token, certificate, or role each environment expects. As enterprises standardize on multi-cloud and hybrid architectures, the winning platforms will be the ones that make cross-cloud trust feel as simple as a native single-cloud feature, while keeping governance centralized.