Learning outcomes
- Separate a SPIFFE ID, SVID, trust domain, bundle, and Workload API.
- Trace attestation and short-lived credential delivery to a workload.
- Validate X.509-SVID or JWT-SVID identity at a service boundary.
- Design trust-domain federation without merging administrative authority.
System and boundaries
A SPIFFE ID is a URI such as spiffe://prod.example/payments/processor. The authority is the trust domain. The path identifies a workload within that domain. A SPIFFE Verifiable Identity Document (SVID) is a short-lived credential that carries one SPIFFE ID. Current common forms are X.509-SVID and JWT-SVID.
A trust bundle contains the public keys needed to authenticate identities in one trust domain. The relationship between bundle and trust-domain name must come from trusted configuration. The Workload API is a local interface that delivers SVIDs and bundles to a workload and streams rotations. It identifies the caller through the implementation's local attestation mechanism. Workloads do not present a bootstrap secret to select any identity they want.
The trust domain is an administrative and cryptographic boundary. Federation lets one domain validate identities from another by obtaining its bundle. It does not merge their namespaces or administration.
Request and decision flow
- A node or workload-identity agent establishes its authority through node attestation.
- The agent observes workload selectors through a protected local path.
- Registration policy maps those selectors to one or more SPIFFE IDs.
- The workload connects to the local Workload API. The endpoint identifies the caller without accepting a self-selected SPIFFE ID.
- The Workload API returns and rotates an SVID plus the relevant trust bundles.
- With X.509-SVID, workloads can establish mutual TLS and validate the peer's chain, URI identity, trust domain, and current bundle. With JWT-SVID, a receiver validates signature, issuer trust domain, audience, time, and expected SPIFFE ID policy.
- Authorization maps the validated SPIFFE ID to an allowed service resource and action.
X.509-SVID binds identity to a connection and private key. JWT-SVID can cross an application intermediary more easily and remains a replayable bearer object unless another profile adds sender constraint. Prefer the credential form that matches the real transport and threat model.
Failure domains
- A broad attestation selector issues a privileged SPIFFE ID to the wrong process.
- A compromised node agent obtains identities for workloads on that node.
- A workload can connect to another workload's Workload API endpoint or socket.
- A validator accepts a bundle without binding it to the claimed trust domain.
- Old bundles remain trusted after rotation or compromise.
- Federation trusts every identity in a foreign domain instead of an explicit subset.
- Two environments reuse one trust domain despite different administration and security posture.
- A JWT-SVID has a broad audience or is replayed.
- Mutual TLS proves workload identity, but authorization allows every authenticated peer.
Test identity issuance and validation independently. A valid SVID for the wrong SPIFFE ID, trust domain, audience, or service must fail authorization even when its cryptography is correct.
Design tradeoffs and residual risk
Short-lived automatic identity reduces secret distribution and revocation dependence. It adds continuous availability and integrity requirements for attestation, issuers, agents, Workload API endpoints, clocks, and bundle rotation.
One large trust domain reduces federation work and increases administrative blast radius. More trust domains improve separation and require deliberate bundle exchange and cross-domain policy. Federation should trust named identities or controlled path patterns, not the abstract existence of a valid foreign SVID.
Residual risk includes compromised identity authorities, node takeover, false selectors, stolen JWT-SVIDs, vulnerable workloads with valid credentials, and authorization drift. SPIFFE authenticates workloads. It does not determine the application action they may perform.
Pomerium boundary
Pomerium can protect service routes and can authenticate according to documented service and certificate capabilities. It does not become a SPIFFE implementation merely because a deployment uses mutual TLS or workload identity. Operators must verify the exact integration that supplies and validates SVIDs and must map validated workload identity into Pomerium or upstream policy explicitly.
Exercise
Design two trust domains for production and staging. Define three SPIFFE IDs, their workload selectors, X.509-SVID lifetimes, Workload API endpoints, trust-bundle delivery, and service authorization. Add federation to one external production domain for one caller only.
Test a staging SVID at production, the correct domain with the wrong path, an old bundle, another local process at the Workload API, a JWT-SVID for the wrong audience, and a valid foreign SVID outside the allowed path. Record the exact failing validator or policy.
Evaluation checklist
- Can the design distinguish ID, SVID, trust domain, bundle, and Workload API?
- Does local attestation select identity without a workload-controlled claim?
- Are SVIDs short-lived and bundles rotated through a protected path?
- Does federation retain separate trust-domain administration and narrow policy?
- Does every authenticated workload still receive resource and action authorization?
Next learning unit
Workload Attestation
Use platform evidence to select a workload identity without treating mutable labels or network location as proof.
