Trust-domain federation

Exchange bundles; multi-cluster, multi-cloud, B2B.

Expert30 min · lesson 13 of 15

Workload identity is most powerful when it works beyond a single cluster. Federation lets separate trust domains — different clusters, clouds, or organizations — authenticate each other’s workloads without merging into one flat, over-trusted network.

Exchange trust bundles, not keys

Two trust domains federate by exchanging trust bundles — the public roots each uses to sign its SVIDs — so a workload in domain A can verify an SVID presented by a workload in domain B, and vice versa. Crucially, only public trust anchors are shared; each domain keeps its own CA and private keys, so federation never means sharing signing secrets or collapsing the domains into one. This preserves the blast-radius boundary: a compromise in one domain does not automatically compromise the other, yet legitimate cross-domain calls are cryptographically authenticated by identity.

federation shares public roots only
# Trust domain A (acme.internal) Trust domain B (partner.io)
# own CA + private key own CA + private key
# │ exchange PUBLIC trust bundles │
# └──────────────◄────►─────────────┘
#
# A workload verifies B's SVID against B's bundle, and vice versa.
# Private signing keys NEVER leave their domain.
# SPIRE: configure a federated bundle endpoint for the other trust domain,
# and mark registration entries to federate with it.

Multi-cluster and cross-organization

Federation enables three important patterns. Multi-cluster: services in different clusters authenticate each other for a mesh that spans clusters, using a shared or federated trust root. Multi-cloud: a consistent identity plane across AWS, GCP, and Azure workloads. And cross-organization (B2B): two companies can let their workloads call each other with mutual, identity-based authentication instead of shared API keys or a flat site-to-site VPN — each keeps its own trust domain and simply federates the roots. In every case, identity, not network reachability, is what grants access, which is exactly the zero-trust model extended across administrative boundaries.

Federating trust domains
what is shared
public trust bundles
verify the other domain’s SVIDs
never private keys
each domain keeps its CA
what it enables
multi-cluster mesh
cross-cluster mTLS
multi-cloud identity
one identity plane
cross-org (B2B)
mutual auth, no shared keys
Federation extends identity across boundaries while keeping domains separate. Share public roots; grant access by identity, not network.
Federation is not merging — keep domains and CAs separate
The safe federation model exchanges only public trust bundles; sharing a private CA key or collapsing two environments into one trust domain destroys the boundary that limits a compromise. Federate roots, keep each domain’s signing keys private, and let identity — not a flattened network — authorize cross-domain calls.