Module 14: Multi-Cluster & Multi-Cloud Security

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

Why This Matters

Most production environments span multiple clusters, clouds, or data centers. Multi-cluster security is not an advanced topic — it is the reality of modern infrastructure. This module teaches you to design trust boundaries and implement federation for real-world deployments.

Lesson Content

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 Use Cases

• 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

• 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

Production Story

A global company expanded from 2 to 8 Kubernetes clusters across 3 clouds. Each cluster had its own identity system — separate Vault instances, separate CAs. After deploying federated SPIRE, all clusters shared trust automatically. Cross-cluster service calls dropped from 500ms (token exchange) to 5ms (direct mTLS).

Career Relevance

Multi-cloud and multi-cluster architectures are the reality for most enterprises. Engineers who can design trust boundaries and implement federation are essential for platform teams at scale.

Key Terms

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

Hands-On Labs

1. Federated Trust Across Two Clusters

   Deploy SPIRE on two clusters and federate them.

   45 min - Advanced

   • Create two Kind clusters
   • Deploy SPIRE on each with different trust domains
   • Exchange trust bundles
   • Deploy services and verify cross-cluster mTLS

   View lab files on GitHub

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