Identity across two cloud providers
There is no single identity plane across clouds, and pretending otherwise is how long-lived access keys end up stored on the other provider. What can be centralised is authentication: one directory, one joiner and leaver process, one place where access is granted and removed. What cannot be centralised is authorisation, because each provider evaluates permissions differently, and a policy that means one thing on one platform has no equivalent on the other. Getting the split right early is far cheaper than reconciling it after an audit.
Can one directory cover both providers?
For human access, yes, and it should. Every major provider federates with an external identity provider over SAML or OIDC, so people authenticate once against your corporate directory and receive short-lived console and command line sessions on each platform. Nobody should hold a native user account on either provider except for a small number of documented break-glass identities.
The joint between the directory and each provider is group membership. Directory groups map to roles on each platform, which means access changes are made in one place and take effect everywhere, and a leaver is removed once. Provisioning those groups automatically, rather than having an administrator recreate them per platform, is what keeps the two estates from drifting into different definitions of the same team.
Break-glass is the deliberate exception and it needs designing rather than tolerating. Each provider requires at least one identity that does not depend on the federation working, because an outage or misconfiguration in the directory would otherwise lock everyone out of everything at once. Those accounts need hardware-backed multi-factor authentication, credentials held under dual control, alerting on any use, and a periodic test that they still function.
Why do permission models not map between providers?
Because they were designed around different primitives, and the differences are structural rather than cosmetic. One platform attaches policies to identities and resources, evaluates explicit denies with priority, and supports organisational guardrails that cap what any account can do. Another assigns roles at scopes in a management hierarchy and layers a separate policy engine for restrictions. A third grants permissions additively through hierarchical inheritance, with denial expressed by a distinct mechanism.
The practical result is that least privilege cannot be copied across. A carefully scoped policy on one provider becomes a set of role assignments plus a separate restriction on the other, and the two will not be exactly equivalent. Anyone who claims to have replicated a permission model exactly has usually replicated the names and not the effect, which is worse than having two acknowledged designs.
What does transfer is the shape of the estate: which environments are isolated from each other, which teams may touch production, which actions require a second person, and which guardrails must hold everywhere. Write those as principles first, then implement them natively on each platform. That is a defensible design, and it survives an audit better than a mapping table asserting that two dissimilar policies are the same.
How should workloads authenticate across providers?
With federated short-lived credentials, never with a stored access key. Every major provider can trust an external OIDC issuer, which means a workload running on one platform can present its native identity token and exchange it for temporary credentials on the other. No secret is stored, nothing needs rotating, and access can be scoped to a specific workload identity rather than to whoever holds the key.
This matters more than any other control in a multi-cloud estate, because a long-lived key for provider A sitting in a secret store on provider B is the single most common way these environments are compromised. The key outlives the project, it is copied into a pipeline, it ends up in an image or a repository, and it grants standing access that no session expiry limits.
Build the pattern once and make it the only supported route. Federated identity from your CI system to both providers, federated identity from workloads on each platform to the other, and a documented, monitored exception process for the rare cases where a static credential is unavoidable. Every exception should have an owner, an expiry and an alert on use.
| Access type | Mechanism | What it removes | What still needs care |
|---|---|---|---|
| Human console and CLI | SAML or OIDC federation from one directory | Native user accounts on each provider | Break-glass identities and their testing |
| Team permissions | Directory groups mapped to native roles | Per-platform access requests | Group provisioning and periodic review |
| Workload to other provider | OIDC token exchange for temporary credentials | Stored access keys and rotation | Trust conditions scoped to one identity |
| CI pipeline to both providers | Federation from the CI system's issuer | Long-lived deployment credentials | Branch and repository conditions in the trust policy |
| Third party or vendor access | Dedicated role with external identifier | Shared credentials | Scope, expiry and evidence of use |
What does an access review look like across two platforms?
Two exports that do not resemble each other, which is why the review has to be anchored in the directory rather than in the providers. Reviewing entitlements per platform means asking managers to interpret role names they have never seen. Reviewing group membership, with a documented mapping from each group to what it permits on each platform, produces a question a manager can actually answer.
The gaps are always in the same three places. Identities that were created natively on a provider and never joined the federation. Service credentials that belong to no person and appear in no directory. And permissions granted directly to an individual rather than through a group, usually during an incident and never removed. All three are found by comparing each provider's identity inventory against the directory, which is a scriptable check worth running monthly.
Audit evidence also has to be assembled deliberately. Each provider produces its own activity log with its own event schema, its own naming and its own retention default, so a question such as who accessed this dataset last quarter cannot be answered in one place unless the logs were being shipped to a common destination from the start. Deciding that destination before the second provider is populated is one of the cheapest decisions available; retrofitting it is not.
What should be central and what has to be built twice?
Central: the directory, group definitions, the joiner and leaver process, the log destination, the secret store, and the policy that says what guardrails must hold everywhere. Built twice: the native permission implementation, the organisational hierarchy and guardrails, the break-glass identities, and the runbook for what to do when access breaks. That division is stable and it reflects where the platforms genuinely differ.
Resist the urge to centralise the permission implementation itself with a tool that claims to manage roles across providers. Those tools model the intersection of what the platforms support, which means the guardrails you most want, the provider-specific ones that cap what an account can do, are the ones least likely to be expressible. Native controls, defined in infrastructure code and reviewed the same way on both sides, get you consistency of process without pretending the models are the same.
An afternoon test: list every long-lived credential for one provider that exists anywhere in the other, including in pipelines, secret stores, container images and configuration. For each, identify the owner, when it was last rotated and what it can do. Most estates find at least one that nobody claims, and that credential is the actual state of your identity boundary regardless of the design document.
Common questions
- Can you use one identity provider for multiple clouds?
- For human access, yes, and you should. Every major provider federates over SAML or OIDC, so people authenticate against one corporate directory and receive short-lived sessions on each platform. Directory group membership becomes the joint: groups map to native roles, access changes happen in one place, and a leaver is removed once. The exception is a small number of documented break-glass identities that must not depend on federation working.
- Why can't cloud permission models be copied between providers?
- They are built on different primitives. One platform attaches policies to identities and resources with explicit denies evaluated first and organisational guardrails capping accounts. Another assigns roles at scopes in a management hierarchy with a separate policy engine for restrictions. A third grants additively through inheritance with denial as a distinct mechanism. Copying names produces policies that are not equivalent in effect, which is more dangerous than maintaining two acknowledged designs.
- How should workloads authenticate to a second cloud provider?
- Through OIDC federation rather than stored credentials. A workload presents its native identity token to the other provider, which trusts the issuer and returns temporary credentials scoped to that specific workload. Nothing needs rotating and nothing can be copied out. A long-lived access key for one provider sitting in a secret store on another is the most common way multi-cloud estates are compromised, because it outlives the project that created it.
- How do you run an access review across two clouds?
- Anchor it in the directory, not the providers. Review group membership with a documented mapping of what each group permits on each platform, because managers cannot interpret native role names they have never seen. Then run a monthly comparison of each provider's identity inventory against the directory to catch the three recurring gaps: natively created accounts outside federation, service credentials belonging to no person, and permissions granted directly to individuals during incidents.
- Should you use a tool to manage cloud permissions centrally?
- Not for the permission implementation itself. Cross-provider role management tools model the intersection of what the platforms support, so the guardrails most worth having, the provider-specific controls that cap what an account can do, are usually the ones that cannot be expressed. Centralise the directory, group definitions, joiner and leaver process, log destination and secret store, then implement permissions natively on each side through infrastructure code reviewed identically.
