Threat-model a multi-cloud access path

Assets and security objectives

Protect application data and actions, human and workload identities, cloud roles, federation rules, routes, gateways, trust bundles, credentials, control planes, decision evidence, and recovery access. Name one objective for each critical resource.

Examples are: only the payroll service in the production trust domain can read the production payroll database; only an authenticated finance administrator through the approved gateway can start an export; a staging workload cannot exchange its identity for a production cloud role; and every cross-cloud action can be traced to its human or workload actor.

Include time. A disabled identity, removed workload, retired route, or revoked trust relationship must stop new actions within a stated bound.

Actors and components

• Human user, browser, command-line client, and administrator.
• Source workload, acting service, target workload, and application.
• Identity providers and workload-identity issuers in each environment.
• Federation or token-exchange services.
• Public and private DNS, load balancers, gateways, service meshes, tunnels, transit networks, and direct service endpoints.
• Cloud IAM, Kubernetes control planes, policy decision points, and policy enforcement points.
• Metadata services, secret managers, certificate authorities, logging systems, and break-glass paths.

One vendor account can contain several boundaries. Different cloud accounts can still share one compromised identity provider or control plane. Draw authority and trust, not logos.

Trust boundaries

Mark each place where one authority accepts another's identity, route, key, policy, or evidence:

1. User identity provider to access gateway.
2. Gateway to upstream application and mesh.
3. Source platform to workload-identity issuer.
4. Source issuer to target federation service.
5. Federation service to target cloud role or credential.
6. Network transit between clouds and termination at each gateway.
7. Cloud control planes and automation that can change routes, policy, trust, or credentials.
8. Application authorization and data boundary.
9. Evidence transfer into a shared investigation system.
10. Break-glass and disaster-recovery paths.

For each boundary, record exact issuer, subject namespace, audience, resource, key or bundle source, network route, policy owner, failure mode, and stale-state limit.

Normal request path

Trace one human-initiated and one workload-initiated request.

For the human path, the user reaches an identity-aware gateway, completes authentication, receives a bounded session, passes route policy, and reaches an authenticated upstream. The application then authorizes the exact object and action.

For the workload path, the source platform attests the workload and issues a short-lived source identity. A federation service validates exact issuer, subject, audience, and environment, maps it to narrow target authority, and issues a short-lived target credential. The target gateway or service validates that credential and performs local authorization.

At every hop, preserve the original subject and current actor when they differ. Record the effective route and policy version.

Failure path: direct service bypass

A protected service can remain reachable through a public address, internal load balancer, cloud peering route, VPN, node port, mesh service address, old DNS name, recovery listener, or another region. The bypass path can skip user authentication, workload federation, route policy, or evidence.

Enumerate addresses from cloud APIs, DNS, Kubernetes, load balancers, routing tables, firewall rules, certificates, and service discovery. Test each from every source zone. The target must authenticate the approved enforcement path or reject the direct request. A private IP is not proof that traffic crossed the intended gateway.

Failure path: federation trust expansion

A rule that trusts an entire external tenant, issuer, repository, cluster, namespace, or trust domain can let an unrelated workload obtain target authority. Mutable claim mapping can let an attacker rename or relabel a workload into a privileged match. Shared audiences can let a valid source token cross resource boundaries.

Create tokens or SVIDs for another environment, tenant, subject path, audience, cluster, and expired workload. Attempt the same exchange. Validate that trust begins from fixed issuer configuration and that target policy grants only the intended resource.

Failure path: control and recovery bypass

Cloud administrators, CI systems, Terraform roles, certificate authorities, DNS owners, and emergency accounts can change or bypass the data path. A compromise in one shared control plane can affect every cloud. Disaster recovery can restore old routes, keys, allowlists, or federation rules.

Test who can modify route tables, gateway policy, identity mappings, trust bundles, and target roles. Restore a staging backup and run the negative path tests again. Break-glass use must create evidence, expire, and receive review.

Design tradeoffs and residual risk

One shared gateway and identity system improves consistency and creates a large blast radius. Independent cloud boundaries improve isolation and add federation, policy, and evidence complexity. Private transit reduces exposure and does not establish identity. Short-lived federation reduces stored keys and adds issuer availability and mapping risk.

Residual risk includes shared administrator compromise, issuer takeover, cloud control-plane actions, route drift, stale bundles, legitimate but compromised workloads, telemetry gaps, and completed application actions. Assign each residual risk an owner and test trigger.

Pomerium boundary

Pomerium can provide an identity-aware route and policy boundary for configured applications in different environments. Operators own cloud routing, direct-origin restriction, identity-provider trust, workload federation, target-cloud IAM, and application authorization. Pomerium cannot enforce traffic that does not pass through its deployed path.

Exercise

Draw a path across two clouds and one on-premises service. Include all public and private addresses, DNS, gateways, issuers, federation rules, control planes, applications, and recovery routes. Attach one owner and one negative test to every trust boundary.

Run the three failure paths. Start from another network route, exchange another environment's identity, and restore an old route or trust configuration in staging. Confirm that the protected action fails and that evidence identifies the attempted bypass.

Evaluation checklist

• Does the model show authority, identity, routing, and control-plane boundaries across every environment?
• Are original subject, acting service, issuer, audience, and target resource preserved?
• Can every direct, internal, recovery, and cross-cloud route be enumerated and tested?
• Do federation rules reject other tenants, clusters, namespaces, subjects, and audiences?
• Can restored or emergency configuration reintroduce a path that current policy removed?