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.

References​