Multi-Cloud IAM Strategy Guide: Unified Identity Across AWS, Azure, and GCP

Most enterprises today operate across multiple cloud providers. Whether by strategic choice, acquisition, or organic growth, the reality is that your workloads, data, and users span AWS, Azure, GCP, and often several SaaS platforms. Each cloud provider has its own IAM model, its own terminology, its own permission boundaries, and its own approach to identity.

This fragmentation creates real risk. An employee might have admin access in AWS but read-only in Azure — or the reverse — and nobody has a unified view. Service accounts proliferate in each cloud without centralized oversight. Offboarding an employee means remembering to revoke access in three separate consoles. Audit evidence requires pulling reports from three different systems and correlating them manually.

A multi-cloud IAM strategy addresses this by establishing a single identity plane that federates into each cloud provider, unified governance that spans all environments, and consistent security policies regardless of where workloads run.

Prerequisites

A central Identity Provider — Microsoft Entra ID, Okta, or Ping Identity serving as your identity hub.
Accounts/subscriptions/projects in two or more cloud providers.
Basic familiarity with IAM concepts in AWS (IAM, Organizations, SSO), Azure (Entra ID, RBAC, subscriptions), and GCP (IAM, projects, organizations).
Organizational commitment to a unified approach rather than cloud-team silos managing identity independently.

Architecture: The Multi-Cloud Identity Model

The Hub-and-Spoke Pattern

The most effective multi-cloud IAM architecture uses a hub-and-spoke model:

Central Identity Provider (Hub)
  ├── SAML/OIDC Federation → AWS IAM Identity Center
  ├── Native Integration → Azure (Entra ID is often the hub itself)
  ├── SAML/OIDC Federation → GCP Cloud Identity / Workforce Identity
  ├── SAML/OIDC Federation → SaaS Applications
  └── SCIM Provisioning → Each cloud's user directory

The central IdP is the single source of truth for human identity. Users authenticate once and receive federated access to whichever cloud provider they need. No cloud-local passwords, no separate MFA enrollment per cloud, no duplicate identity management.

Comparing Cloud IAM Models

Concept	AWS	Azure	GCP
Identity source	IAM Identity Center, IAM users	Entra ID	Cloud Identity, Workforce Identity Federation
Permission model	IAM policies (JSON)	Azure RBAC (role assignments)	IAM policies (role bindings)
Permission boundary	AWS account	Subscription / Resource group	Project / Folder
Service identity	IAM roles (for services)	Managed Identities	Service accounts
Privilege escalation risk	Inline policies, wildcard actions	Owner role, custom role creation	Primitive roles, setIamPolicy
MFA	IAM MFA, Identity Center MFA	Entra conditional access	Cloud Identity MFA settings
Audit logging	CloudTrail	Activity Log, Sign-in logs	Cloud Audit Logs

Federation Architecture Deep Dive

AWS IAM Identity Center (formerly AWS SSO):

Central IdP → SAML 2.0 → AWS IAM Identity Center
                              ↓
                    Permission Sets (mapped to IdP groups)
                              ↓
                    AWS Accounts (via AWS Organizations)

Permission sets define what users can do in each AWS account. Map IdP groups to permission sets and accounts to create your access model.

Azure (when Entra ID is not the hub):

If your central IdP is Okta or Ping, federate into Entra ID:

Central IdP → SAML/OIDC → Entra ID (External Identity)
                              ↓
                    Azure RBAC Role Assignments
                              ↓
                    Subscriptions / Resource Groups

GCP Workforce Identity Federation:

Central IdP → OIDC → Workforce Identity Pool
                          ↓
                    IAM Role Bindings (with principal identifiers)
                          ↓
                    GCP Projects / Folders / Organization

Step-by-Step Implementation

Step 1: Establish Your Central Identity Provider

If you do not already have a single IdP, choose one and migrate all human identity management to it. The three common choices:

Microsoft Entra ID — Natural choice if you are a Microsoft shop. Native integration with Azure, strong SAML/OIDC federation for AWS and GCP.

Okta — Cloud-native, strong federation support for all three providers, good SCIM provisioning.

Ping Identity — Strong enterprise features, good for complex hybrid environments.

Regardless of your choice, the central IdP must:

Be the authoritative source for group membership
Enforce MFA policies consistently
Support SAML 2.0 and OIDC for federation
Support SCIM for automated provisioning
Provide comprehensive audit logging

Step 2: Federate Into Each Cloud Provider

AWS Federation via IAM Identity Center:

In the AWS Management Console, navigate to IAM Identity Center.
Choose "External identity provider" as the identity source.
Configure SAML federation with your central IdP:
- Upload IdP metadata (or enter issuer URL and certificate).
- Download the AWS SAML metadata and register it in your IdP.
Enable automatic provisioning (SCIM) to sync users and groups.
Create permission sets that map to your access model.
Assign IdP groups to permission sets and AWS accounts.

Azure Federation (if not using Entra as hub):

Configure your IdP as an external identity provider in Entra ID.
Set up B2B direct connect or cross-tenant access settings.
Map external groups to Azure RBAC roles on subscriptions and resource groups.

GCP Federation via Workforce Identity:

Create a Workforce Identity Pool in GCP.
Configure an OIDC provider pointing to your central IdP.
Map IdP attributes (groups, email) to GCP principal identifiers.
Bind IAM roles to workforce identity principals:

gcloud projects add-iam-policy-binding my-project \
  --member="principalSet://iam.googleapis.com/locations/global/workforcePools/my-pool/group/developers" \
  --role="roles/viewer"

Step 3: Design a Unified Permission Model

Each cloud uses different terminology and structures for permissions. Create an abstraction layer that maps your organizational roles to cloud-specific permissions:

organizational_role: "Platform Engineer"
description: "Engineers who build and maintain cloud infrastructure"
cloud_permissions:
  aws:
    permission_set: "PlatformEngineer"
    accounts: ["infrastructure-prod", "infrastructure-staging"]
    policies:
      - arn:aws:iam::aws:policy/PowerUserAccess
      - custom:DenyBillingAccess
  azure:
    role: "Contributor"
    scope: "/subscriptions/infra-sub/resourceGroups/platform-rg"
    deny_assignments:
      - "Microsoft.Authorization/roleAssignments/write"
  gcp:
    role: "roles/editor"
    projects: ["infra-prod", "infra-staging"]
    deny_policies:
      - "iam.serviceAccounts.actAs"

organizational_role: "Security Analyst"
description: "Security team members who monitor and investigate"
cloud_permissions:
  aws:
    permission_set: "SecurityAnalyst"
    accounts: ["ALL"]  # read access to all accounts
    policies:
      - arn:aws:iam::aws:policy/SecurityAudit
      - arn:aws:iam::aws:policy/ReadOnlyAccess
  azure:
    role: "Security Reader"
    scope: "/subscriptions/*"  # all subscriptions
  gcp:
    role: "roles/iam.securityReviewer"
    resource: "organizations/123456"  # org-wide

Step 4: Manage Service and Workload Identities

Human identity federation is the easier problem. Service and workload identities across clouds are harder because each cloud handles them differently.

Principles for multi-cloud workload identity:

No long-lived credentials — Use workload identity federation (AWS IRSA/Pod Identity, Azure Managed Identity, GCP Workload Identity) instead of access keys.
Cross-cloud access via federation — When a workload in AWS needs to access a GCP resource, use OIDC federation rather than embedding GCP service account keys in AWS.
Centralized inventory — Maintain a single registry of all service/workload identities across all clouds, including their permissions and owners.

Cross-cloud workload identity example (AWS to GCP):

AWS EKS Pod → IRSA (get AWS credentials)
    ↓
AWS STS → AssumeRoleWithWebIdentity
    ↓
GCP Workload Identity Pool (trusts AWS STS as token issuer)
    ↓
GCP IAM role binding → GCP resource access

This allows an application running in AWS to access GCP resources using short-lived, automatically rotated credentials without storing any secrets.

Step 5: Implement Unified Governance

Centralized access reviews:

Your IGA platform should review access across all cloud providers in a single certification campaign. The reviewer should see "User X has these permissions in AWS, these in Azure, and these in GCP" — not three separate certification campaigns.

Unified audit and compliance:

Aggregate cloud audit logs into a single SIEM or security data lake:

AWS CloudTrail → S3 → Log Aggregation Pipeline
Azure Activity Logs → Event Hub → Log Aggregation Pipeline  → SIEM
GCP Audit Logs → Pub/Sub → Log Aggregation Pipeline

Create cross-cloud correlation alerts:

"User was deprovisioned in the central IdP but still has active sessions in AWS."
"Service account in GCP was granted admin permissions but has no corresponding change ticket."
"Privileged access was used in Azure outside of the PIM activation window."

Cross-cloud SoD rules:

Define segregation of duties that span clouds:

A developer with deploy access in AWS should not also have deploy access in the disaster recovery GCP environment.
A user with billing access in one cloud should not have billing access in another (unless explicitly approved).

Step 6: Automate with Infrastructure as Code

Manage IAM configuration across all clouds using IaC:

Terraform example (multi-cloud IAM):

# AWS Permission Set
resource "aws_ssoadmin_permission_set" "platform_engineer" {
  name             = "PlatformEngineer"
  instance_arn     = aws_ssoadmin_instance.main.arn
  session_duration = "PT4H"
}

# Azure Role Assignment
resource "azurerm_role_assignment" "platform_engineer" {
  scope                = azurerm_resource_group.platform.id
  role_definition_name = "Contributor"
  principal_id         = azuread_group.platform_engineers.object_id
}

# GCP IAM Binding
resource "google_project_iam_binding" "platform_engineer" {
  project = "infra-prod"
  role    = "roles/editor"
  members = [
    "principalSet://iam.googleapis.com/locations/global/workforcePools/main/group/platform-engineers",
  ]
}

Store all IAM configuration in Git with mandatory pull request reviews. No manual IAM changes in any cloud console.

Best Practices

Establish a Cloud IAM Center of Excellence

Do not let each cloud team manage IAM independently. Establish a cross-cloud IAM team or CoE that owns the federated identity architecture, permission model standards, and governance processes across all cloud providers.

Normalize Permission Levels

Create an organizational permission taxonomy that maps consistently across clouds:

Read-only = AWS ReadOnlyAccess / Azure Reader / GCP Viewer
Operator = AWS specific service permissions / Azure Contributor (scoped) / GCP Editor (scoped)
Admin = AWS AdministratorAccess (scoped) / Azure Owner (scoped) / GCP Owner (scoped)
Billing = AWS Billing / Azure Billing Reader / GCP Billing Account Viewer

Monitor for Drift

IAM configurations drift when someone makes a manual change in a cloud console that is not reflected in your IaC. Use drift detection tools (Cloud Custodian, Prisma Cloud, custom scripts) to detect and alert on IAM changes made outside of your automation pipeline.

Implement Break-Glass Per Cloud

Each cloud needs its own break-glass mechanism that does not depend on federation:

AWS: IAM user with MFA in the management account (not federated)
Azure: Break-glass Entra ID accounts (cloud-only, excluded from conditional access)
GCP: Super admin account in Cloud Identity (not federated)

Testing

Federation testing — Verify that SAML/OIDC authentication works correctly for each cloud. Test with users in different groups to verify permission mapping.
Deprovisioning testing — Disable a test user in the central IdP and verify that access is revoked in all three clouds within your target time window.
Cross-cloud access testing — Test workload identity federation between clouds (e.g., AWS pod accessing GCP bucket).
Audit trail testing — Perform sensitive actions in each cloud and verify they appear in your centralized SIEM with correct user attribution.

Common Pitfalls

Managing Identity Per Cloud

The biggest anti-pattern is treating each cloud's IAM as a separate system. This leads to inconsistent permissions, duplicated effort, and gaps in governance. Even if federation is not perfect, it is always better than independent identity management per cloud.

Ignoring Cloud-Specific Nuances

While you should unify governance, you cannot ignore the differences in how each cloud handles IAM. AWS IAM policies are JSON documents with explicit deny semantics. Azure RBAC uses role definitions and scope hierarchies. GCP IAM uses allow policies at the resource level. Your unified model must account for these differences, not paper over them.

Overcomplicating the Permission Model

The temptation with multi-cloud is to create an elaborate abstraction that covers every possible scenario. Start simple: 3-5 organizational roles mapped to each cloud. Add complexity only when real-world requirements demand it.

Not Accounting for Latency in Federation

Federated authentication adds latency compared to cloud-native authentication. For time-sensitive workloads (CI/CD pipelines, automated deployments), ensure your federation setup does not create bottlenecks. Use cached tokens and workload identity federation for automated processes.

Conclusion

Multi-cloud IAM is not about choosing the lowest common denominator across cloud providers. It is about establishing a unified identity plane that leverages each cloud's strengths while maintaining consistent governance, visibility, and security. The hub-and-spoke federation model, combined with Infrastructure as Code and centralized governance, gives you control without sacrificing the flexibility that multi-cloud provides.

Start by federating human identity through a single IdP, then address workload identity with federation rather than static credentials, and finally implement unified governance with cross-cloud certification campaigns and audit correlation. The investment in multi-cloud IAM coherence pays dividends in security, compliance, and operational efficiency.

Frequently Asked Questions

Q: Should we use a single IdP or cloud-native identity for each provider? A: Use a single IdP for human identity, federated into each cloud. This provides consistent MFA, lifecycle management, and governance. For workload identity, use each cloud's native mechanisms (IAM roles, managed identities, service accounts) with workload identity federation for cross-cloud access.

Q: How do we handle acquisitions that bring a new cloud provider? A: Federate the new cloud provider into your existing hub IdP. Map the acquired company's roles to your organizational permission model. Run a parallel period where both the old and new IAM configurations are active, then sunset the acquired company's independent identity setup.

Q: What about cloud providers that do not support SAML or OIDC? A: Most modern cloud and SaaS providers support at least SAML 2.0. For providers that only support API keys or basic authentication, use a secrets management vault as an intermediary and implement your own access governance layer around credential issuance.

Q: How do we audit access across all clouds? A: Aggregate audit logs from all clouds into a single SIEM. Create standardized reports that show who accessed what, in which cloud, and when. Use your IGA platform for access certification campaigns that span all clouds.

Q: Is it realistic to manage all cloud IAM through IaC? A: For planned, steady-state IAM configurations, yes. IaC should be the standard path for all IAM changes. However, you need emergency/break-glass processes for urgent changes, with a reconciliation process that brings manual changes back into IaC afterwards.