Multi-cloud identity is one human directory, plus a separate workload identity per provider, plus explicit trust for any cross-cloud API call. Federate people through Microsoft Entra ID, Okta or another IdP into AWS IAM Identity Center, Azure RBAC and Google Cloud IAM. Give workloads IAM roles, managed identities or Workload Identity Federation. Do not copy long-lived access keys into the second cloud. Each provider's IAM language is different, so a role in AWS is not an Azure role assignment. Documentation dated 2026-08-30 is the source for each product. Shared passwords across clouds are not a design.

The single-cloud baseline is IAM fundamentals. Whether a second cloud is justified at all is single cloud vs multi-cloud.

Assumptions

  • Humans already have, or will have, one corporate IdP. The sections below map that IdP into each cloud. They do not pick Okta versus Entra.
  • Workload identity is per provider. Cross-cloud API calls need an OIDC or STS trust you can list.
  • AWS Organizations, one Entra tenant and a Google Cloud organization are three identity roots. Alibaba RAM is a fourth.
  • This is the trust map, not a landing-zone build. Control Tower appears only where Identity Center is the human path.

Humans: one IdP, three permission models

AWS IAM Identity Center (used by Control Tower) maps IdP groups to permission sets, then to accounts in Organizations. Azure RBAC maps Entra groups to roles on management groups, subscriptions and resource groups. Google Cloud IAM maps Cloud Identity or Workforce Identity Federation groups to roles on organizations, folders and projects.

Keep the group names aligned (cloud-platform-admins, payments-prod-read) and keep the permission documents separate. An AWS permission set that includes AdministratorAccess is not the same as Azure Owner and not the same as roles/owner. Write the mapping table. Do not assume the IdP group is the permission.

Break-glass users belong in each provider’s native directory, stored offline, and used only when the IdP or Identity Center is down. The lockout path is IAM access lockout.

Workloads: federation, not keys in env vars

A container on EKS that must call Azure Storage should use IAM roles for service accounts, then an OIDC trust that Azure accepts, or a short-lived token broker you control. Google Cloud Workload Identity Federation lets an AWS role or an Azure managed identity mint Google credentials without a downloaded JSON key. Azure federated credentials on a user-assigned managed identity accept GitHub or other OIDC issuers.

Pattern that fails in reviews: an IAM user access key stored in Kubernetes Secrets, used from two clouds. Rotation is manual. Leak blast radius is both bills and both data planes.

Pattern that holds: each runtime has a native identity. Cross-cloud calls use OIDC or a documented STS assume-role. There is no long-lived shared secret.

Inventory the trusts you already created

aws iam list-open-id-connect-providers --output table
aws iam list-roles --query "Roles[?contains(AssumeRolePolicyDocument, 'sts.amazonaws.com') == \`false\`].RoleName" --output text

list-open-id-connect-providers returns every OIDC issuer the account trusts (EKS, GitHub Actions, Google, a custom broker). An empty list in an account that still has static keys is a smell. The second command is a starting point only. Read each role’s trust policy. Look for Federated principals and for AWS principals in another account or another cloud’s STS.

Azure:

az ad sp list --filter "servicePrincipalType eq 'ManagedIdentity'" --query "[].{name:displayName,appId:appId}" -o table

Google Cloud:

gcloud iam workload-identity-pools list --location=global

An empty workload-identity-pool list with a directory full of *.json keys means federation was never finished.

Organizations and tenants are identity boundaries

AWS Organizations SCPs limit principals in member accounts. They do not apply to the management account. Azure landing zones assume one Entra tenant for the platform landing zone. A second tenant is a second identity island. Google Cloud’s organization resource is the IAM root. Crossing organizations is a migration, not a role assignment.

If two clouds share a company, still treat the AWS organization, the Entra tenant and the Google Cloud organization as three roots. A contractor who is a Guest in Entra is not automatically in IAM Identity Center. Invite and map them, or they will ask for an IAM user.

Alibaba Cloud RAM users and Resource Directory members are a fourth model. Do not rename RAM to IAM. See Alibaba Cloud architecture for APAC workloads.

What multi-cloud identity is not

It is not a single RBAC engine. Products that claim to wrap all four providers still emit native role bindings. You debug those bindings in the native console when something pages.

It is not directory sync of every AD group into every cloud. Sync the groups that map to permission sets. Leave HR groups out.

It is not identical MFA policy unless you enforce MFA at the IdP and disable local console passwords. AWS root users, Entra break-glass and Google Cloud super-admins still need hardware keys.

Risks and limitations

OIDC thumbprints and issuer URLs expire or get rotated by the platform. EKS cluster rebuilds create a new OIDC provider. Update the IAM OIDC provider or assume-role starts failing with AccessDenied, which looks like an application bug.

Workforce Identity Federation and External Identities have session and attribute limits. Test group claim size before you put 400 AD groups on one user.

SCPs, Azure Policy and organization policies can deny the sts:AssumeRole or token-exchange APIs you need for federation. Land those exceptions in the landing zone, not in a hotfix on the first deploy.

Related pages: IAM fundamentals and the cloud glossary.

Official sources