Module 14 of 16

Multi-Cluster & Multi-Cloud Security

Federation, cross-cloud identity, hybrid infrastructure, and trust boundaries at scale

3 hours1 labsFree

Start here

Learning objectives

  • Design trust boundaries for multi-cluster deployments
  • Implement SPIFFE federation across clusters and clouds
  • Secure hybrid infrastructure (Kubernetes + VMs)
  • Plan cross-cloud identity portability
MULTI-CLUSTER FEDERATED TRUSTAWS ClusterSPIRE Server (aws.company.org)Service AService BGCP ClusterSPIRE Server (gcp.company.org)Service CService DOn-Prem VMsSPIRE Server (onprem.company.org)Legacy APIDatabaseFederationFederationThree trust domains, federated. Services in any domain can verify identities from any other.

Most organizations eventually outgrow a single cluster. Multi-cluster, multi-cloud, and hybrid deployments introduce trust boundary challenges that single-cluster security models cannot handle.

Trust Domain Design

Each cluster or cloud region gets its own SPIFFE trust domain. Trust domains are federated by exchanging trust bundles. Services in any domain can verify SVIDs from any federated domain.

Cross-Cloud Identity

SPIFFE identity is cloud-agnostic. A service running on AWS can verify the identity of a service running on GCP — if both trust domains are federated. No cloud IAM roles, no cloud-specific tokens, just SPIFFE SVIDs.

Hybrid Infrastructure

SPIRE supports both Kubernetes and VM workloads. Kubernetes uses k8s_psat attestation, VMs use AWS IID, Azure MSI, or join token attestation. Both participate in the same trust domain and can verify each other.

Trust Boundaries

  • Within a trust domain: All workloads share the same CA. Any registered workload can get an SVID. Identity is verified locally by the SPIRE Agent.
  • Across trust domains: Federation via bundle exchange. Identity verification requires the remote trust bundle. More controlled — you choose which domains to federate with.
  • Between organizations: Separate trust domains with explicit federation. Full organizational boundary isolation.

Real world

Where this shows up

  • Multi-cluster identity for global deployments
  • Cross-cloud trust between AWS and GCP
  • Hybrid identity for Kubernetes + VM workloads
  • Organizational mergers requiring trust domain federation

Common mistakes

What usually breaks

  • Using one trust domain for everything (no blast radius isolation)
  • Not planning trust domain names before deployment (hard to rename)
  • Federating without understanding the security implications (full trust of remote domain)
  • Different security policies across clusters without coordination

Key terms

Vocabulary used in this module

Trust Domain

Root of trust identified by a domain name, corresponding to one SPIRE Server

Federation

Cross-trust-domain trust via bundle exchange

Trust Bundle

CA certificates used to verify SVIDs from a trust domain

Hybrid Infrastructure

Mix of Kubernetes, VMs, and cloud services in one architecture

Labs

Hands-on labs

45 minAdvanced

Federated Trust Across Two Clusters

Deploy SPIRE on two clusters and federate them.

  1. Create two Kind clusters
  2. Deploy SPIRE on each with different trust domains
  3. Exchange trust bundles
  4. Deploy services and verify cross-cluster mTLS
View lab on GitHub

Recap

Key takeaways

  • Each cluster/cloud gets its own trust domain — federate to enable cross-domain trust
  • SPIFFE identity is cloud-agnostic — works across AWS, GCP, Azure, and on-prem
  • Trust boundaries should align with organizational boundaries
  • Federation is explicit — you choose which domains to trust
  • Hybrid identity (K8s + VMs) works with different attestation plugins in the same domain

Related resources

Keep learning across CodersSecret