The Identity Translation Layer Is Where Multi-Cloud Security Fails

We spent a decade arguing over whether multi-cloud was an architectural mistake, while missing the far more immediate hazard: no two cloud providers evaluate identity the same way, and the translation layer between them is full of security blind spots.

When security teams talk about multi-cloud risk, they usually point to operational overhead, fragmented logging, or the sheer velocity of cloud-native deployment. But infrastructure sprawl is manageable. Infrastructure is deterministic; security groups, subnets, and storage buckets behave predictably regardless of where they live. The real vulnerability lives higher in the stack, in the subtle, structural incompatibilities between AWS IAM, Google Cloud IAM, and Microsoft Entra ID (formerly Azure AD).

Trying to map an organization’s access control requirements across these three platforms creates an identity impedance mismatch. Because security teams rely on third-party security platforms or simplified identity abstraction layers to manage this mess, they end up with a false sense of control. They build rules on top of abstractions that don’t hold up under real-world testing.

Structural Impedance: How Clouds Actually Evaluate Intent

The fundamental mistake is treating cloud IAM models as interchangeable dialects of the same access language. They aren’t. They are entirely different formal systems with distinct evaluation logic, inheritance rules, and failure modes.

AWS IAM is intensely resource- and policy-centric. Evaluation is stateless and explicit: request context (principal, action, resource, environment conditions) is run against a combination of identity-based policies, resource-based policies, permissions boundaries, and Service Control Policies (SCPs). Unless an explicit allow exists—and no explicit deny overrides it—the request fails. Crucially, context keys like aws:PrincipalArn or aws:SourceVpc allow deep runtime enforcement directly at the policy engine level.

Google Cloud IAM, by contrast, is structural and hierarchical. Permissions are almost never granted directly; they are bundled into Roles, which are bound to Members at specific nodes in a resource hierarchy (Organization -> Folder -> Project -> Resource). GCP identity relies heavily on Service Accounts, which uniquely act as both principals (identities that perform actions) and resources (objects that other identities can access via iam.serviceAccounts.actAs). If an engineer misinterprets how inheritance flows down a GCP folder branch, or fails to realize that granting access to a Service Account resource is functionally equivalent to handing over its credentials, access leaks down the hierarchy in ways that an AWS-trained engineer will completely miss.

Microsoft Entra ID introduces a distinct split between the Directory Plane (tenant-wide object management) and the Control/Resource Plane (Azure RBAC). Access in Azure relies on object assignments scoped to Management Groups, Subscriptions, Resource Groups, or individual resources. Add Conditional Access policies, Enterprise Applications, Service Principals, and Application Registrations into the mix, and identity scope becomes decoupled from resource context in a way that neither AWS nor GCP replicates.

When you try to enforce “Least Privilege” across all three, you aren’t writing one policy in three formats. You are attempting to translate a declarative evaluation policy (AWS) into a hierarchical binding tree (GCP) and an object-tenant assignment model (Azure). The seams where those translations fail are where initial access turns into platform compromise.

The Invisible Pivot: Cross-Cloud Workload Identity

Where this structural mismatch turns dangerous is in modern multi-cloud workload identity federation. Long-lived static credentials like AWS access keys or GCP service account keys are rightly frowned upon, so organizations predictably turned to OpenID Connect (OIDC) federation. A service running in GCP assumes an AWS IAM Role via Web Identity Federation; a Kubernetes pod in Azure accesses a GCP bucket using Workload Identity.

Federation solves the secret rotation problem, but it creates a massive trust mapping problem.

Consider a GCP-to-AWS federation setup. AWS trusts Google’s OIDC issuer (accounts.google.com) and relies on an IAM Role trust policy to evaluate incoming assertions. The AWS policy author uses condition keys to limit access:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "accounts.google.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "accounts.google.com:sub": "109876543210987654321"
        }
      }
    }
  ]
}

This looks secure, but it breaks down in the details. The sub (subject) claim in a GCP OIDC token corresponds to the unique, immutable ID of a GCP Service Account. If the security team setting up this trust assumes that sub maps to a human user email, or if they scope the condition to trust an entire GCP project’s service accounts using wildcards on custom attributes without understanding how GCP issues identity tokens for workloads, they open an unintended trust window.

If an attacker achieves remote code execution inside any low-privilege workload in that GCP project that has permission to impersonate or generate tokens for that specific GCP Service Account, they instantly cross the cloud boundary into AWS. Worse, from the AWS perspective, the call comes from a legitimate federated principal executing a valid STS exchange. CloudTrail logs the STS assume-role event, but it has zero visibility into the upstream GCP identity lifecycle or whether the GCP principal was compromised minutes prior.

No single cloud provider’s native telemetry sees both sides of this pivot point. AWS sees a valid JWT assertion; GCP sees a standard service account token generation. The attack lives entirely in the semantic gap between them.

Why Security Platforms Fail to Bridge the Gap

To solve this visibility issue, organizations deploy Cloud Infrastructure Entitlement Management (CIEM) and Cloud Native Application Protection Platforms (CNAPP). Marketing materials promise a “single pane of glass” that standardizes identity governance across all environments.

In practice, these tools achieve multi-cloud coverage by abstracting identity to its lowest common denominator. They pull down IAM definitions via API, convert them into an internal graph model, and present a unified view of “Effective Permissions.”

This abstraction is fundamentally flawed because it hides the cloud-specific evaluation quirks where real vulnerabilities live:

1. Deny Logic Mismatches: AWS explicit denies supersede everything, including resource-based policies. Azure denied assignments behave differently, and GCP IAM simply lacks a direct inline “explicit deny” model in the traditional sense (outside of Organization Policy constraints or IAM Deny policies, which operate under strict limitations). A CIEM tool showing “effective access” frequently miscalculates how dynamic evaluation engines resolve competing policies.
2. Context-Aware Conditions: A tool analyzing an AWS IAM policy can read s3:GetObject, but it cannot dynamically evaluate runtime condition keys like aws:VpcSourceIp or custom HTTP header checks unless it actively simulates the policy evaluation engine. Most don’t. They flag the role as “Overprivileged Admin Access” when, in reality, access is heavily constrained by network context. Conversely, they mark federated trust relationships as “Low Risk” because they only see a limited set of permissions, completely missing the scope of the trusted identity on the remote cloud side.
3. Identity vs. Resource Boundary Blindness: In Azure, an identity might have broad permissions at a scope, but be restricted by resource-provider level locks or directory-level flags. Abstracting this to a simple “User X can write to Storage Y” graph node flattens the actual defensive boundaries, leading to both false positives and dangerous false negatives.

By flattening these nuanced engines into a generic model, security tools create a false sense of security. They give security teams dashboard metrics to report to executives while missing the actual mechanics of cross-cloud privilege escalation.

Structural Hardening Over Abstraction

Solving this problem doesn’t mean abandoning multi-cloud, nor does it mean buying another security aggregator. It requires accepting that cross-cloud identity transitions are high-risk boundaries that must be engineered with explicit, defense-in-depth controls rather than soft trust mappings.

To harden identity across cloud boundaries, focus on structural boundaries over centralized visual dashboards:

Strict Claim Mapping and Attribute Pinning

Never federate identity across clouds based solely on issuer parameters. When configuring OIDC trust relationships (such as AWS IAM Role trust policies accepting tokens from Azure or GCP), explicitly enforce exact claim matches on immutable identifiers. Pin the subject (sub), audience (aud), and specific workspace/tenant IDs. If the target cloud supports attribute-based access control (ABAC) via federated claims, explicitly map those claims to context-restricted session tags, and evaluate them strictly at runtime.

Asymmetrical Architecture for Cross-Cloud Workloads

Treat cross-cloud workload access like an untrusted third-party integration. If an application running in Azure needs to pull data from an AWS S3 bucket, do not give the Azure workload direct credentials or broad cross-cloud assume-role capabilities to S3. Force the interaction through a tightly scoped API gateway, a serverless broker, or a dedicated token-exchange proxy that validates state, logs source context, and performs explicit runtime authorization before issuing a short-lived scoped token.

Native Policy Validation Pipelines

Stop relying on third-party security platforms to catch IAM errors after deployment. Move identity policy validation into the CI/CD pipeline using native, engine-aware tools. Use AWS IAM Access Analyzer and parliament for AWS policies; use GCP’s IAM Simulator and policy intelligence APIs for Google Cloud; use Azure Policy and Entra ID access reviews for Microsoft environments. Run validation against the native engines before infrastructure is provisioned, rather than trying to analyze normalized representations after the fact.

Assume Cross-Cloud Identity Compromise

Design cross-cloud privilege models assuming that an identity operating in Cloud A will be compromised. Define strict resource control boundaries in Cloud B that prevent lateral movement even if the federated identity is fully hijacked. In AWS, this means applying restrictive Service Control Policies (SCPs) and Resource-Based Policies that limit federated session capabilities regardless of the permissions attached to the assumed role. In GCP, it means enforcing strict VPC Service Controls around data projects to block egress, even if a compromised federated service account has administrative IAM permissions.

Identity is the control plane of modern cloud architecture, but it is not a uniform execution layer. The multi-cloud identity risk isn’t that you have resources in two different places—it’s that you’re relying on security assumptions that break the moment your identity crosses the boundary between them.