What problem does SPIFFE solve?

The default way services authenticate to each other is a stored credential: an API key in an environment variable, a client secret in a config file, a token baked into a container image. Every one of those is a long-lived secret that has to be distributed, rotated, and protected, and any one that leaks keeps working until someone notices. In a cluster running hundreds of workloads, that is a large, quiet attack surface.

SPIFFE removes the stored secret entirely. A workload's identity is established by attestation, proving what the workload is from properties the platform can observe, and the credential it receives is short-lived and rotated for it. There is no password to copy, because there is no password.

What is a SPIFFE ID and an SVID?

A SPIFFE ID is a URI that names a workload, in the form spiffe://trust-domain/path, for example spiffe://example.org/ns/default/sa/payments. The trust domain is the root of trust, usually an organization or a cluster, and the path identifies the specific workload within it.

An SVID, a SPIFFE Verifiable Identity Document, is the credential a workload presents to prove its SPIFFE ID. It comes in two forms. An X.509-SVID is an X.509 certificate that carries the SPIFFE ID in its URI subject alternative name, and it is what workloads use to establish mTLS with each other. A JWT-SVID is a signed JWT carrying the SPIFFE ID, used where a certificate does not fit, such as calls through a layer-7 gateway. Both are short-lived by design and are rotated automatically, so a leaked SVID is only useful for the brief window before it expires.

How does a workload get a SPIFFE identity?

SPIFFE is the specification; SPIRE, the SPIFFE Runtime Environment, is the production implementation that issues the identities. It has two parts. The SPIRE Server is the signing authority for a trust domain, effectively its certificate authority, and it holds the registration entries that say which workloads may receive which SPIFFE IDs. A SPIRE Agent runs on each node, typically as a Kubernetes DaemonSet.

Getting an identity happens through attestation, with no pre-shared secret. First the agent proves the identity of the node it runs on, node attestation, often using a cloud provider's instance identity document. Then it identifies each local workload asking for a credential, workload attestation, using selectors the platform exposes, such as the Kubernetes service account or the process's Unix user. Only once both check out does the server issue the workload an SVID, delivered through SPIRE's Workload API and rotated on a short TTL, commonly around an hour. No secret is ever stored in the workload.

How does SPIFFE relate to mTLS?

X.509-SVIDs are certificates, so SPIFFE and mTLS fit together directly. Two workloads that each hold an X.509-SVID can open a mutually authenticated TLS connection, present their SVIDs, and verify each other against the trust domain's bundle, the set of CA certificates used to validate SVIDs from that domain. The SPIFFE ID in each certificate tells the other side exactly which workload it is talking to.

That is what makes SPIFFE the identity layer under most zero-trust service meshes: every service-to-service call is mutually authenticated by a short-lived, attested identity rather than trusted because of the network it came from. It is the same machine-to-machine problem, solved with rotating certificates instead of stored secrets.

How does MonoCloud use SPIFFE?

MonoCloud consumes SPIFFE identities to extend that trust from inside the cluster out to your APIs. You register your SPIRE trust bundle in MonoCloud as a source of trust, the same way you would any online or offline certificate authority. A workload then opens an mTLS connection to MonoCloud and authenticates with its X.509-SVID, MonoCloud validates it against the SPIRE trust bundle, applies your access policy, and issues a certificate-bound access token (RFC 8705) tied to that SVID. The workload uses that token to call APIs inside or outside the mesh, and each API can confirm the token matches the presenting SVID, so a copied token fails anywhere else.

Two things make this fit short-lived workload identity well. Validation is built for rotating certificates, with expiry checks, revocation, and tunable cache windows, and access is decided per workload: a Cedar policy evaluated at token issuance decides which APIs each workload may reach. To note plainly, MonoCloud does not replace SPIRE, SPIRE still issues the SVIDs; MonoCloud trusts them and turns them into scoped API access. See the MonoCloud mTLS page, or start building for free.

Frequently asked questions

What is SPIFFE?

SPIFFE, the Secure Production Identity Framework for Everyone, is an open CNCF standard for giving software workloads a cryptographic identity so they can authenticate without stored secrets. Each workload gets a SPIFFE ID and a short-lived, verifiable credential called an SVID, which replaces long-lived API keys and client secrets in clusters and service meshes.

What is an SVID?

An SVID, a SPIFFE Verifiable Identity Document, is the credential a workload presents to prove its SPIFFE ID. It comes as an X.509-SVID, a certificate carrying the SPIFFE ID in its URI subject alternative name and used to establish mTLS, or a JWT-SVID, a signed JWT for cases where a certificate does not fit. Both are short-lived and rotated automatically.

What is the difference between SPIFFE and SPIRE?

SPIFFE is the specification, the format of the identity and the SVID. SPIRE is the production implementation that issues them. A SPIRE Server acts as the certificate authority for a trust domain, and a SPIRE Agent on each node attests workloads and delivers their SVIDs through the Workload API.

How does SPIFFE work without secrets?

Through attestation. A SPIRE Agent first proves the identity of its node, then identifies each local workload using platform selectors such as the Kubernetes service account or Unix user. Only when both check out does it issue a short-lived SVID, rotated on a TTL of roughly an hour. No password or key is stored in the workload, so there is nothing to leak.

Does MonoCloud replace SPIRE?

No. SPIRE still issues the SVIDs. MonoCloud consumes them: you register your SPIRE trust bundle, workloads authenticate to MonoCloud with their X.509-SVID over mTLS, and MonoCloud issues a certificate-bound access token scoped by policy, extending the workload's identity from the cluster to your APIs.