Day 6: SPIFFE Federation — Crossing Trust Domain Boundaries

Phase 4 · August 10, 2026

Agenda (2–3 hours)

• Read (60 min): SPIFFE Federation spec; SPIRE federation docs
• Study (45 min): How trust bundles are exchanged; which scenarios need federation
• Challenge (45 min): Design a federation topology for a multi-org scenario

Why Federation Exists

A single trust domain is fine when all services are within one organization.

But workloads increasingly need to talk across organizations:

• Your provisioning service at leo.amazon.com calls a partner API at partner.org
• A satellite terminal's CA is operated by a different team than your provisioning service
• Dev/staging/prod are separate trust domains for isolation

Federation lets workloads in different trust domains verify each other's SVIDs
without sharing a CA or having a common root.

How SPIFFE Federation Works

Two SPIRE servers establish a trust bundle exchange:

SPIRE Server A (leo.amazon.com)          SPIRE Server B (partner.org)
    CA cert A → published at             CA cert B → published at
    https://leo.amazon.com/bundle        https://partner.org/bundle

Each server fetches the other's bundle and distributes it to agents.
Workloads in domain A receive domain B's bundle → can validate B's SVIDs.

The bundle endpoint is a simple HTTPS GET returning a JWK Set:

{
  "keys": [
    { "kty": "EC", "crv": "P-256", "x": "...", "y": "...", "use": "x509-svid" }
  ],
  "spiffe_refresh_hint": 3600
}

Federation Modes

Static bundle exchange (simplest):

• Manually copy trust bundle from domain B into domain A's SPIRE config
• No ongoing sync; suitable for stable, slow-changing relationships
• Config: federation.refresh_hint tells how often to re-fetch

Dynamic bundle exchange (production):

• SPIRE servers poll each other's bundle endpoints
• Bundle automatically updates when the remote CA rotates
• Config: federation.bundle_endpoint_profile = https_spiffe or https_web

SPIRE Federation profile https_spiffe:

• The bundle endpoint itself is authenticated using an SVID
• More secure, requires bootstrapping — the two servers exchange root certs first

Trust Domain Relationship Model

                    ┌─────────────────┐
                    │  leo.amazon.com │
                    │   SPIRE server  │
                    │  (your domain)  │
                    └────────┬────────┘
                             │  bundle exchange
                    ┌────────┴────────┐
                    │   partner.org   │
                    │   SPIRE server  │
                    │  (partner CA)   │
                    └─────────────────┘

Your workload (leo.amazon.com/svc/provisioning) calls partner.org/svc/consumer:
1. Your workload presents its SVID (from leo.amazon.com CA)
2. partner.org validates it using leo.amazon.com's bundle
3. partner.org workload presents its SVID (from partner.org CA)
4. Your workload validates it using partner.org's bundle

What Federation Enables vs. What It Doesn't

What it enables:

• Cross-organization mTLS using workload identity (not static certs)
• Automatic trust rotation — when a remote CA rotates, bundles update
• Fine-grained authorization — you can allow specific SPIFFE IDs from another domain

What it doesn't replace:

• Authorization policy (you still need to check SPIFFE IDs, not just validate the cert)
• Network-level controls (firewall, VPC)
• The bootstrapping step (you need an out-of-band first exchange)

For your provisioning service: federation is relevant if you call external partners
or if your prod/dev environments are separate trust domains.

Relevance to Amazon Leo

Amazon Leo operates satellite internet infrastructure. Consider:

• Device domain: satellite terminals might be a separate trust domain
  (their certs come from a different CA hierarchy you don't control)
• Service domain: internal microservices share the leo.amazon.com trust domain
• Customer domain: enterprise customers running their own CA for device auth

Federation would let your provisioning service validate device SVIDs from
the device trust domain — but note that satellites can't run SPIRE agents.
This is the same tension from Day 2: SPIFFE assumes ephemeral compute, not embedded hardware.

Challenge Assignment

Design a federation topology on paper (sketch or markdown table):

Scenario: Your provisioning service needs to call three types of peers:

1. Internal microservices (same team, same AWS account)
2. A partner firmware signing service (different organization, firmwaresign.example)
3. Satellite terminals (embedded hardware, no SPIRE agent)

For each peer type:

1. What trust domain does it belong to?
2. Is federation needed? Why or why not?
3. If federation is needed: static or dynamic bundle exchange?
4. If SPIFFE doesn't apply: what credential mechanism would you use instead?

Write your answers in spiffe-analysis.md under a "Federation Design" section.
This thinking is directly applicable to Phase 6's integration project.

Resources

• SPIFFE Federation spec: github.com/spiffe/spiffe/blob/main/standards/SPIFFE_Federation.md
• SPIRE federation docs: spiffe.io/docs/latest/architecture/federation/
• Blog: "Federated SPIFFE Identity at Uber" (CNCF blog)