SPIFFE JWT-SVID Cross-Trust-Domain Federation Review Prompt
Review SPIRE federation and JWT-SVID validation across trust domains — audience binding, bundle exchange, and short TTLs — so a workload in one domain can authenticate to another safely.
- Target user
- Platform and identity engineers federating SPIFFE/SPIRE across clusters, clouds, or org boundaries
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT
The prompt
You are a senior workload-identity engineer who has federated SPIFFE/SPIRE trust domains in production and knows the failure modes of JWT-SVIDs across boundaries. I will provide: - The trust-domain topology (which domains, which clusters/clouds, who owns each) — [TOPOLOGY] - How federation is configured today (SPIRE federation, bundle endpoints) — [FEDERATION CONFIG] - Where JWT-SVIDs vs X.509-SVIDs are used and the relying parties — [SVID USAGE] - The validation code/config on the receiving side — [VALIDATION] Your job, step by step: 1. **Map the trust graph** — state which domain trusts which, how trust-bundle exchange happens (federation bundle endpoint, manual, watch), and whether bundle rotation is automated. Flag any one-way trust that should be one-way and any that is accidentally bidirectional. 2. **JWT-SVID audience binding** — verify every relying party validates the `aud` claim against *its own* identifier and rejects tokens minted for a different audience. Flag any relying party accepting any audience or a wildcard — this is the classic cross-domain confused-deputy bug. 3. **Issuer/trust-domain validation** — confirm the receiver validates the SPIFFE ID's trust domain and the signing key against the *federated* bundle for that domain, not a blanket trust of any signer. 4. **TTL and revocation** — review SVID TTLs (short is good), how bundle rotation propagates, and what happens to in-flight tokens when a domain's keys rotate. 5. **X.509 vs JWT choice** — assess whether JWT-SVIDs are used where X.509-SVID mTLS would be stronger (e.g. service-to-service inside the mesh), since JWTs are bearer tokens and replayable until expiry. 6. **Bundle endpoint security** — review how the federation bundle endpoint is authenticated (https_spiffe vs https_web) and whether a compromised endpoint could inject a rogue bundle. Output as: (a) the trust-graph summary with flagged asymmetries, (b) a findings table (issue, risk, evidence, fix) ordered by severity, (c) the corrected validation config/code, (d) the bundle-rotation runbook. Present as a review for the identity owners to action — call out any place where the supplied config does not show audience or trust-domain validation, and do not assume it is present.
Why this prompt works
SPIFFE federation is where workload identity gets genuinely dangerous, because crossing a trust-domain boundary turns a clean local guarantee into a distributed trust problem. The single most common bug is a relying party that accepts a JWT-SVID without binding the aud claim to itself — a confused-deputy hole that lets a token minted for one service be replayed against another across the federation. This prompt puts audience validation front and center and explicitly hunts for wildcard or any-audience acceptance.
The review framing forces the model to reason about the trust graph as a directed structure, not a vague “these clusters trust each other.” Asymmetric trust is usually the correct design, and the prompt flags accidental bidirectional trust and asks how a rogue federated bundle would even be detected — questions teams skip when they get federation working and stop looking. It also pushes the JWT-versus-X.509 decision, because JWT-SVIDs are bearer tokens and replayable until expiry, where X.509-SVID mTLS is not.
By demanding evidence for each finding and calling out where the supplied config simply does not show audience or trust-domain validation, the prompt avoids the trap of assuming the safe behavior is present. The output is a severity-ordered review with corrected config and a rotation runbook — a draft for the identity owners to verify and action, which is the right division of labor when the subject is who is allowed to be whom across an organizational boundary.