Skip to main content

SPIFFE support

This document provides a high-level overview of SPIFFE support in Avassa. It explains the core SPIFFE concepts and how Avassa uses them for workload authentication and federation.

For step-by-step configuration and examples, see Authenticate with JWT-SVID.

SPIFFE concepts​

SPIFFE defines a workload identity framework based on:

  • SPIFFE ID: a URI that identifies a workload, for example spiffe://example.org/ns/prod/sa/web.
  • Trust domain: the namespace that owns SPIFFE IDs, commonly mapped to an organization or environment.
  • SVIDs (SPIFFE Verifiable Identity Documents): credentials that carry the SPIFFE ID.

SPIFFE defines two primary SVID types:

  • X.509-SVID: an X.509 certificate where the SPIFFE ID is carried in the URI SAN. This is typically used for mTLS.
  • JWT-SVID: a JWT that includes the SPIFFE ID in the sub claim and is signed by the trust domain.

Federation​

SPIFFE supports federation across trust domains by exchanging trust bundles (public keys / CA certificates). This allows a workload from one trust domain to authenticate to a service in another trust domain using its SPIFFE ID and SVID.

How Avassa uses SPIFFE​

Avassa supports SPIFFE for both inbound and outbound authentication:

  • Inbound: an external workload can authenticate to Avassa using a JWT-SVID. Strongbox verifies the JWT-SVID against configured trust material (JWKS or static keys), validates audience and expiry, and maps SPIFFE IDs to token policies.
  • Outbound: workloads started by Avassa can be issued a JWT-SVID and/or X.509-SVID at login. These SVIDs can be presented to external systems that trust the configured issuer or CA.

X.509-SVID for mTLS​

X.509-SVIDs are well suited for workload-to-workload mTLS. Each side presents its X.509-SVID and verifies the peer against the trusted SPIFFE CA bundle. Authorization is typically based on the SPIFFE ID in the URI SAN rather than DNS or CN fields.

Trust bundle distribution​

For workloads that receive SVIDs to verify them, they need access to verification material:

  • JWT-SVID verifiers need the public signing key (as a JWKS document).
  • X.509-SVID verifiers need the issuing CA certificate (as a PEM bundle).

Strongbox provides two unauthenticated RPCs for this:

  • get-spiffe-jwks: returns the JWKS public key set for the tenant's JWT-signing transit key.
  • get-spiffe-bundle: returns the PEM CA certificate for the tenant's SPIFFE issuing CA.

These endpoints are public (no token required) so that external services and service meshes can fetch verification material without needing a Strongbox account. This preserves the zero-touch workload identity model that is central to SPIFFE.

For usage examples, see Fetch the SPIFFE trust bundle.

References​