SPIFFE / SPIRE

SPIFFE vs SPIRE

SPIFFE is the standard and SPIRE is one of the implementations.

SPIFFE ID and SVID

SPIFFE ID is the name, SVID is the passport.

1. The SPIFFE ID (The "Identity")

The SPIFFE ID is a structured string (URI) that identifies a workload. It defines who the workload is, but it carries no cryptographic weight on its own. It is just a name.

Format: spiffe://trust-domain/workload-identifier
Example: spiffe://prod.acme.com/billing/payment-processor
Purpose: To provide a consistent, platform-independent naming convention for services across different clouds or data centers.
Analogy: Your Social Security Number or your unique username. It identifies you, but you can’t use just the "string" of your SSN to board an airplane.

2. The SVID (The "Document")

SVID stands for SPIFFE Verifiable Identity Document. This is the cryptographic credential used to prove the SPIFFE ID. An SVID contains the SPIFFE ID within it.

Format: Currently, there are two types of SVIDs:
1. X.509 SVID: A standard public key certificate (used for mTLS). The SPIFFE ID is encoded in the "Subject Alternative Name" (SAN) field.
2. JWT SVID: A JSON Web Token (used for app-level authentication). The SPIFFE ID is encoded in the "sub" (subject) claim.
Purpose: To provide the actual "proof" that a workload is entitled to that identity. It is signed by a Certificate Authority (CA) that the rest of the system trusts.
Analogy: Your physical Passport. It is a document issued by an authority that contains your name (SPIFFE ID) and has security features (holograms/signatures) to prove it’s authentic.

How they work together (The Workflow)

When you use a tool like SPIRE (the most popular implementation of SPIFFE) to secure your AI agents or microservices:

Attestation: The SPIRE agent looks at the workload (using the Attestation methods we discussed earlier) and confirms it is the "healthy" payment-processor.
Issuance: Once satisfied, SPIRE generates an SVID (the certificate).
Embedding: Inside that certificate, SPIRE writes the SPIFFE ID (spiffe://prod.acme.com/billing/payment-processor).
Communication: When the payment-processor talks to the database, it presents the SVID. The database looks at the SVID, verifies the signature, and reads the SPIFFE ID inside it to decide if access should be granted.

Why have both?

This separation allows for Agility. You can keep the same SPIFFE ID for a service for years, but you can rotate and change the SVID (the certificate) every 15 minutes. This ensures that if a certificate is stolen, it becomes useless very quickly, while your security policies (which refer to the SPIFFE ID) don't have to be updated constantly.

So SVID is not a new type of a document, but a standard format (jwt or x509) used specifically in the SPIFFE context?

Yes. An SVID is exactly that: a specific "flavor" or profile of an X.509 certificate or a JWT.

Think of it like a Standard Passport. A passport is just a booklet with paper and ink (the format), but what makes it a "Passport" (the SVID) is that it follows a very strict international agreement on where your photo goes, what the chips inside store, and who is allowed to sign it.

GCP uses `principal://`, is it standard SPIFFE?

No, principal:// is not standard SPIFFE.

While the two often appear together in Google Cloud Platform (GCP) configurations, they serve two completely different purposes in a Zero Trust architecture.

spiffe:// is a Standard Identity Format: It is the "Name" of the workload, recognized globally by any system that follows the SPIFFE standard. SPIFFE ID is a platform-agnostic URI.
principal:// is a GCP IAM Identifier: It is a Google-specific "Pointer" used inside GCP’s Identity and Access Management (IAM) system to tell Google which specific identity (which could be a SPIFFE ID) is allowed to access a resource.

How it works:

The Workload: Presents a SPIFFE SVID (a certificate) that says: "I am spiffe://prod/billing-app."
The Handshake: GCP verifies the certificate using Workload Identity Federation.
The Mapping: GCP looks at its IAM policy and sees a rule:

"Allow principal://.../subject/spiffe://prod/billing-app to read from this Cloud Storage bucket."
The Result: Because the SPIFFE ID matches the subject in the principal:// string, access is granted.

In short: principal:// is not a SPIFFE ID, but it is Google's "IAM-native" way of representing one.