SPIFFE secrets engine

Enterprise

Appropriate Vault Enterprise license required

The Secure Production Identity Framework For Everyone (SPIFFE) spiffe secrets engine mints JWT-based SPIFFE Verifiable Identity Documents (SVIDs). SVIDs come in two forms: an X.509 certificate or a JWT. The sub claim of the token is a SPIFFE ID, and because the tokens are OIDC-compatible, anything that already knows how to validate an OIDC ID token can validate them.

If you need X.509 certificate-based identity, use the PKI secrets engine.

Use cases

A workload that already holds a Vault token (from any auth method) needs a portable identity token to present to another service's SPIFFE authentication workflow, an OIDC-aware relying party, or any service that accepts JWTs.
You want identity tokens where the sub claim follows the spiffe://<trust-domain>/… URI format, without deploying a separate SPIFFE-compatible service.

SPIFFE auth method vs. SPIFFE secrets engine

Use the following table to determine which plugin to use based on your workflow.

Use the SPIFFE secrets engine (secrets/spiffe) when you are already logged into Vault (using Kubernetes, AppRole, AWS, or another auth method) and want Vault to issue you a SVID.
Use SPIFFE auth (auth/spiffe) when you have SPIRE (or another SPIFFE issuer) running and want to log into Vault using a SVID.

	SPIFFE auth method	SPIFFE secrets engine (this page)
Direction	A workload presents an SVID to Vault to log in	Vault mints a JWT-SVID for a caller already logged in
What it needs	A trust bundle to validate incoming SVIDs against	Nothing external — it's its own signer
What it returns	A Vault token	A JWT-SVID

Architecture

Vault is the issuer of the SVID, not the consumer. The SPIFFE secrets engine is a standalone JWT signer. It generates and rotates its own signing key and has no dependency on the PKI secrets engine, an external CA, or other SPIFFE-compatible service.

Each mount has a single trust domain. Roles define a claims template using the same templating language as the OIDC tokens issued by the Identity secrets engine. The fields available to interpolate depend on the auth method the workload uses to authenticate with Vault, for example Kubernetes auth metadata or AppRole. Vault always populates iss, aud, iat, exp, and a vault.entity.id claim; role templates cannot override these fields.

The following diagram shows the request flow when a workload fetches a JWT-SVID from Vault:

  [ Workload ]                                        [ Vault ]
  (already authenticated                              (mints and signs
   by any other method)                                 the JWT-SVID)
       │                                                    │
       │──(1. Request JWT-SVID, mintjwt)──────────────────> │
       │ <──────────────────(2. JWT-SVID)────────────────── │
       │
       │──(3. Present JWT-SVID)──────────────────> [ Relying party ]
                                                     (validates via JWKS,
                                                      accepts)

Supported SVID types

Vault's SPIFFE secrets engine mints JWT-based SVIDs:

JWT-SVIDs: Vault generates a short-lived, signed JWT where the sub claim is a SPIFFE ID (spiffe://<trust-domain>/…). The token is OIDC-compatible and can be validated by any OIDC-aware relying party using the mount's JWKS endpoint.

Vault mints X.509-SVIDs using the PKI secrets engine.

Next steps

Enable and set up the SPIFFE secrets engine, configure the trust domain, and define roles.
Mint SVIDs with Vault and verify a JWT-SVID end to end.