Federation

A federation establishes a trust relationship between two trust zones, enabling workloads in each to validate certificates issued by the other. This page covers how to create federations and how to configure workloads to make use of them.

Creating a federation

Federations are unidirectional: adding a federation from trust zone A to trust zone B means A trusts B, but not necessarily the reverse. For mutual TLS between workloads in two trust zones, you need a federation in each direction.

cofidectl federation add \
  --trust-zone trust-zone-a \
  --remote-trust-zone trust-zone-b

cofidectl federation add \
  --trust-zone trust-zone-b \
  --remote-trust-zone trust-zone-a

Once both federations are in place, the Cofide SPIRE servers in each trust zone will exchange trust bundles, making it possible for workloads to validate certificates from the other trust domain.

Enabling workloads to trust a federated trust domain

Creating a federation is necessary but not sufficient for a workload to validate certificates from a remote trust domain. A federation makes the remote trust bundle available to the SPIRE server, but each workload only receives that bundle if its attestation policy binding explicitly opts in using the --federates-with flag.

Without --federates-with, the workload’s SPIRE registration entry will not reference any federated trust domains. When the workload fetches credentials via the Workload API, it will only receive its own trust domain’s bundle, and will reject any certificate from the remote trust domain as untrusted, even if a federation exists.

To include the remote trust bundle in the identities issued to a workload, pass --federates-with when creating the attestation policy binding:

cofidectl attestation-policy-binding add \
  --trust-zone trust-zone-a \
  --attestation-policy my-policy \
  --federates-with trust-zone-b

This can be repeated for multiple federated trust zones:

cofidectl attestation-policy-binding add \
  --trust-zone trust-zone-a \
  --attestation-policy my-policy \
  --federates-with trust-zone-b \
  --federates-with trust-zone-c

Important

Both the client and server workloads need --federates-with pointing at the other’s trust zone. If only the client opts in, the client can validate the server’s certificate but the server will reject the client’s.

Summary

Setting up cross-trust-zone mTLS requires three things:

1. A federation from trust zone A to trust zone B.
2. A federation from trust zone B to trust zone A.
3. Attestation policy bindings for both the client and server workloads that include --federates-with pointing at the other trust zone.

Step 3 is easy to miss because the federation appears to be in place and SPIFFE IDs are being issued correctly, but the workloads are still only carrying their own trust domain’s bundle.