How to Run One Application Across Multiple Clouds Under One Identity Model

To run one application across multiple clouds under one identity model, keep one source of truth for people (a central identity provider federated into every cloud) and one logical identity per workload that each cloud maps to its own native principal through federation, so no cloud holds long-lived keys. Then standardize authorization, service-to-service mTLS, and audit on top, and plan for the identity provider or one cloud being unavailable.

This guide walks through each layer of multi-cloud identity, maps each mechanism to AWS, Google Cloud, and Azure, and covers what breaks when the identity provider, a token issuer, or a cloud fails.

Disclosure: Control Plane publishes this guide.

TL;DR

The model has seven parts, followed by where Control Plane fits. People and workloads come first, and the rest build on them.

• People. A central identity provider (Okta, Microsoft Entra ID, Google Workspace, or similar) federated via SAML or OIDC into every cloud, with SCIM provisioning for users and groups where the IdP supports it.
• Workloads. One logical identity per workload, mapped to a native principal in each cloud through workload identity federation. No long-lived keys.
• Service to service. mTLS between services, with certificates rotated frequently and tied to workload identity.
• Authorization. One application role model, explicitly mapped to least-privilege cloud-native permissions in each provider.
• Secrets. Short-lived credentials wherever possible. When secrets are unavoidable, store them in a dedicated secrets manager with policy-gated access.
• Audit. Centralized, tamper-resistant audit logs from every cloud, correlated by identity.
• Failure planning. Test what happens when the identity provider, a cloud region, or a token issuer is unreachable.
• Where Control Plane fits. Control Plane gives each workload one identity across every location it runs in, connects it to AWS, GCP, and Azure services through Control Plane’s Universal Cloud Identity, enforces mTLS between workloads, and keeps a tamper-proof audit trail.

How do I run the same application across multiple clouds under one identity model?

Follow these steps in order. Each one builds on the previous.

1. Inventory every principal. Catalog people (employees, contractors), CI/CD pipelines, and application workloads that touch any cloud. Include service accounts, API keys, and any long-lived credentials.

2. Choose the source of truth for people. Pick one central identity provider. This is the authoritative directory for human users, groups, and lifecycle events (onboarding, offboarding, role changes). Okta, Microsoft Entra ID, and Google Workspace are common choices. The identity provider must support SAML or OIDC for federation, and should support SCIM for automated provisioning where the cloud accepts it.

3. Federate each cloud to your identity provider. Configure each cloud to trust your identity provider for workforce sign-in. AWS uses IAM Identity Center, Google Cloud uses Workforce Identity Federation (no user sync) or Cloud Identity single sign-on with synced users, and Azure uses Entra ID, either as the identity provider itself or federated to an external SAML or WS-Fed identity provider. Map groups from your identity provider to cloud-specific roles so that group membership drives permissions.

4. Define one logical identity per workload. Each distinct service or application component gets one identity name, such as payments-api-prod. This identity is the unit of access control, secrets access, and audit attribution across every cloud.

5. Map each workload identity to a native principal in every cloud through federation. Use workload identity federation so the workload proves who it is with a short-lived token from a trusted issuer (such as a Kubernetes cluster or a SPIRE server), and the cloud exchanges that token for temporary, scoped credentials. Some platforms broker the exchange instead. On Control Plane, the platform obtains short-lived credentials for the workload’s identity and serves them inside the workload where the provider’s SDK already looks. No static keys are stored in code or environment variables. AWS documents this as AssumeRoleWithWebIdentity, Google Cloud as Workload Identity Federation, and Azure as federated identity credentials on Entra Workload ID.

6. Standardize authorization. Define one set of application roles (reader, deployer, operator, auditor) and map each to the minimum cloud-native permissions required. Use policy as code to version, review, and enforce these mappings.

7. Encrypt and authenticate service-to-service traffic. Require mTLS between every service. Each workload should present a certificate tied to its identity, rotated on a short cadence. Deny traffic to a new workload by default, and open it only through an explicit rule.

8. Centralize audit. Aggregate audit logs from every cloud into one system. Each log entry should include the identity that performed the action, the resource affected, and the timestamp. Incident response and compliance audits depend on this attribution.

9. Test identity during failover. Resilience is a common reason to run across clouds. Test authentication and authorization with the identity provider, a token issuer, or one cloud region unreachable, and repeat these drills on a schedule.

Which service handles each identity layer in AWS, Google Cloud, and Azure?

Each cloud has its own service for every layer. The portable column lists an open standard, an open-source project, or a platform such as Control Plane that works the same way in every cloud.

How do I give a container the same identity in every cloud?

A container proves its identity with a short-lived token, typically an OIDC token, instead of a stored key. Each cloud accepts that token and exchanges it for temporary, scoped credentials to its own services.

Consider a workload called payments-api running in production. It needs to read from Amazon S3, write to BigQuery on Google Cloud, and send messages through Azure Service Bus. You define one logical identity, payments-api-prod, and configure each cloud to trust the token issuer that the workload uses. The workload’s Kubernetes service account token, a SPIRE-issued JWT-SVID, or a platform-issued token serves as the proof. For a deeper explanation of the federation mechanism, see workload identity federation explained.

One workload identity mapped to three clouds

Three details matter in every cloud:

• Issuer. The OIDC issuer URL must be registered in the cloud’s trust configuration. This is the Kubernetes cluster’s OIDC discovery endpoint, a SPIRE OIDC discovery provider, or a platform’s token issuer. The cloud must be able to fetch the issuer’s discovery document and JWKS signing keys, unless you upload the JWKS directly (Google Cloud allows this).
• Subject and audience scoping. The trust must be scoped to a specific subject claim (such as a Kubernetes namespace and service account name) and audience. Without this scoping, any workload that can obtain a token from the same issuer can assume the cloud principal.
• Short-lived credentials. The cloud credentials returned by the exchange are temporary. Each cloud’s SDK reads them through its default credential chain once the token file and target principal are configured. No static key is stored in the container image, environment variable, or deployment manifest.

When you need one workload to use services from multiple clouds in a single application, the identity holds grants for each cloud, and the workload’s SDK handles credential retrieval per provider.

How should authorization work across clouds?

A common identity does not mean common permissions. AWS IAM policies, Google Cloud IAM bindings, and Azure role assignments use different semantics, different resource hierarchies, and different default behaviors. An “admin” in one cloud is not automatically equivalent to an “admin” in another.

The practical approach is to define one application role model with clear, abstract roles such as reader, deployer, operator, and auditor. Each role carries a written description of what it is allowed to do in business terms. Then you explicitly map each role to the minimum cloud-native permissions required in each provider.

Maintain these mappings in version-controlled policy as code. Terraform or Pulumi modules declare the cloud-native IAM bindings, and OPA (Open Policy Agent) through Conftest, HashiCorp Sentinel, or Pulumi CrossGuard checks those plans against your rules before apply. OPA can also evaluate authorization decisions inside the application. Review the mappings on a regular cadence and whenever a cloud provider changes its IAM model. For a detailed approach, see policy as code for multi-cloud IaC governance.

Key principles:

• Grant least privilege per cloud. A workload that only reads from S3 gets s3:GetObject on one bucket, even if it also writes to BigQuery.
• Avoid wildcard resource scoping in any cloud.
• Separate human and workload permissions. Humans need console access and break-glass procedures. Workloads need API access with no interactive login.
• Audit permission drift. Compare actual cloud IAM state against your policy as code definitions on a schedule.

What happens to identity when a cloud, region, or identity provider fails?

Access fails in predictable ways when the identity provider, a token issuer, a region, or a federation trust breaks. Plan for each case before it happens.

Which platforms unify identity, deployment, and billing across clouds?

Three broad approaches exist, and they differ in how much per-cloud identity, deployment, and billing plumbing your team owns.

A central identity provider plus per-cloud tooling. You run your own identity provider, configure federation into each cloud, and use separate deployment pipelines per cloud. This gives maximum control but requires significant operational investment to keep federation trusts, IAM mappings, and deployment configurations consistent.

A multi-cloud Kubernetes setup with a workload identity system. You run Kubernetes clusters in each cloud, use SPIFFE/SPIRE or each cloud’s native workload identity mechanism, and manage deployments through GitOps or a shared CI/CD pipeline. This works well for teams already invested in Kubernetes but still requires you to manage cluster-level identity, networking, and policy alignment across clouds.

A platform layer that gives each workload one identity across clouds. A platform abstracts the per-cloud identity plumbing so that a workload deployed to multiple clouds gets one identity, one set of policies, and one audit trail. The platform handles federation, credential exchange, and mTLS internally. The trade-off is that workloads must run on the platform to benefit, so check whether it also runs on Kubernetes clusters you already operate and on premises.

Choose the first for full control of each cloud, the second if you already run Kubernetes in every cloud, and the third to hand federation, credential exchange, and mTLS to a platform.

How Control Plane fits

Control Plane is the unbreakable platform for running production workloads. It runs serverless, standard, stateful, and cron workloads natively on AWS, GCP, Azure, and Oracle Cloud Infrastructure (OCI), VM workloads on locations joined through Control Plane’s Managed Kubernetes, and workloads on Kubernetes clusters you already run or your own machines, including on premises, active-active across regions and clouds.

One identity per workload, everywhere it runs. A Control Plane identity is attached to a workload and is its whole credential surface. An identity belongs to a Global Virtual Cloud (GVC), which is Control Plane’s named set of locations drawn from cloud regions, Kubernetes clusters you register, and your own hardware. Because the identity belongs to the GVC, the same workload identity applies in every location the workload runs in. A workload takes at most one identity, and every container in that workload shares it.

Universal Cloud Identity for cloud services. Universal Cloud Identity, Control Plane’s workload identity for cloud services, connects a workload to AWS, GCP, or Azure services through an IAM role or service-account grant instead of long-lived keys in your code, with short-lived, least-privilege credentials at runtime. One identity holds at most one AWS, one GCP, and one Azure cloud account, so a workload that reads from Amazon S3 and writes to BigQuery uses one identity. The principal lives in your own cloud account. Control Plane creates an IAM role on AWS, a service account on GCP, or a managed identity or app registration on Azure, or attaches an existing AWS role or GCP service account you name. The provider’s own SDK finds the credentials without extra configuration. For a walkthrough, see how to run the same app on AWS, GCP, and Azure.

mTLS between workloads. Traffic between workloads uses mTLS with a unique client certificate per workload, rotated hourly. A new workload accepts no inbound or outbound internet traffic and no traffic from other workloads until you allow it.

Secrets with policy-gated access. A workload reads a secret only when a policy grants its identity reveal on that secret. The container references it as cpln://secret/name. For more on this pattern, see secrets management best practices.

People and automation. People sign in to the Control Plane console with single sign-on through Google, GitHub, Microsoft, or SAML, and their access is set by group membership and policies. Groups can hold users and service accounts. CI pipelines and automation use service accounts.

Audit. Control Plane keeps a tamper-proof audit trail of every action taken through the console, CLI, Terraform, Pulumi, Control Plane’s Kubernetes operator, and the Control Plane MCP server, since all of them call the same API, recording who did what across the org. Your own workloads can write events to it through an audit context.

Policies. Inside a Control Plane org, nothing is permitted until a policy grants it. Policies only grant, so you narrow access by granting less, and a policy can target resources by tag query, so resources created later are covered with no policy edit.

Day 2 operations. Control Plane handles Day 2 operations for you, including autoscaling, built-in observability, and security. The 99.999% availability SLA applies to workloads running at least two replicas in at least two locations. Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant.

Scope. Control Plane identities belong to workloads running on Control Plane, in every location their GVC spans, including Kubernetes clusters you already run and your own machines. Universal Cloud Identity covers AWS, GCP, and Azure.

FAQ

Short answers for teams planning multi-cloud identity.

How do I run the same application across multiple clouds under one identity model?

Keep one central identity provider for people, federated into every cloud via SAML or OIDC. Give each workload one logical identity that maps to a native principal in each cloud through workload identity federation, using short-lived credentials. Standardize authorization with one role model mapped per cloud, enforce mTLS between services, centralize audit, and test identity behavior during failover.

How to give a container identity across multiple clouds?

Define one logical identity for the container workload and register the token issuer (a Kubernetes OIDC endpoint, SPIRE, or a platform) as a trusted identity provider in each cloud. The container presents a short-lived OIDC token, and each cloud exchanges it for temporary, scoped credentials to its own services. Scope the trust to a specific subject and audience so that only that workload can assume the cloud principal.

What is workload identity federation?

Workload identity federation is a mechanism where a cloud provider trusts tokens issued by an external identity system instead of requiring static credentials. The workload presents a token from a trusted issuer, and the cloud exchanges it for short-lived credentials scoped to a specific role or service account. This eliminates the need for long-lived API keys stored in code or environment variables. AWS, Google Cloud, and Azure all support this pattern natively.

Do I need SPIFFE/SPIRE to run an app across clouds?

No. Each major cloud supports OIDC-based workload identity federation natively, and platforms like Control Plane give each workload its own identity and obtain each cloud’s short-lived credentials for it. SPIFFE/SPIRE is a strong choice if you need a vendor-neutral identity layer across heterogeneous environments, including on-premises infrastructure.

Should I use one identity provider for all clouds?

Yes, for people. A single identity provider as the source of truth for workforce identity simplifies onboarding, offboarding, MFA enforcement, and group-based access control. Federate it into every cloud rather than maintaining separate user directories per cloud. For workloads, the trust anchor is the token issuer (a Kubernetes cluster, SPIRE, or a platform), which is usually separate from the workforce identity provider.

How do I avoid long-lived cloud keys in a multi-cloud app?

Use workload identity federation. Configure each cloud to trust a token issuer, and let workloads exchange short-lived tokens for temporary cloud credentials at runtime. Each cloud’s SDK refreshes the exchanged credentials before they expire. Remove any static API keys from environment variables, container images, and deployment manifests. Audit for lingering long-lived credentials on a regular schedule.

What happens if my identity provider goes down?

People cannot sign in to cloud consoles or internal tools until the identity provider recovers. Workloads federated through a cluster, SPIRE, or platform issuer keep working, unless the identity provider that is down is Entra ID, which also issues Azure workload tokens. Workloads that get tokens from the identity provider cannot obtain new ones. Cloud sessions and cloud credentials already issued keep working until they expire. Prepare by maintaining break-glass accounts in each cloud that do not depend on the identity provider, protected by hardware MFA keys stored offline, setting session lifetimes that balance security with resilience, and testing identity provider failover if your provider supports it.

Which enterprise platforms unify identity, billing, and deployment across multiple clouds?

Options range from assembling your own stack (a central identity provider, per-cloud IAM, separate deployment pipelines) to running a multi-cloud Kubernetes setup with SPIFFE/SPIRE, to using a platform that abstracts per-cloud identity and deployment into one layer. Control Plane unifies identity, billing, and deployment in one platform. A workload deployed once to a Global Virtual Cloud runs in every location it spans, every org on a billing account shares one invoice itemized per org, each workload has one identity, Universal Cloud Identity reaches AWS, GCP, and Azure services, and one audit trail records every action taken through Control Plane.

How does Control Plane give a workload one identity across clouds?

A Control Plane identity is attached to a workload and belongs to a Global Virtual Cloud (GVC). The workload runs in every location the GVC spans, whether AWS, GCP, Azure, or Oracle Cloud regions, Kubernetes clusters you registered, or your own hardware, and it carries the same identity in each. For cloud services, Universal Cloud Identity uses a principal in your own AWS, GCP, or Azure account, and Control Plane serves that provider’s own instance metadata endpoint inside the workload, so an unmodified SDK picks up short-lived, least-privilege credentials.

Can I use Control Plane for end-user authentication in my application?

Yes, for validating tokens on incoming requests, while your identity provider handles sign-in and stays the user directory. JWT authentication in each workload’s Envoy sidecar, set per workload or for a whole GVC, validates tokens from your identity provider by issuer and audience and can pass claims to your code as request headers. To host the identity provider yourself, Control Plane’s Template Catalog includes Keycloak, FusionAuth, and Logto.

To give your workloads one identity across every cloud, talk to the Control Plane team or sign up free.

Originally published on the Control Plane blog.