In a service mesh, the caller is often a service, job, container, function, or agent rather than a person. A SPIFFE ID gives that workload a URI-form name within the SPIFFE workload-identity framework. section 11.1.2
A SPIFFE ID identifies which workload is making a request and supports proof of that identity through a SPIFFE Verifiable Identity Document (SVID). It does not decide whether the request is authorized: a policy engine such as Cedar evaluates the authenticated identity alongside the action, resource, and runtime context. section 11.1.2 section 12.5.2
SPIFFE IDs participate in an authorization architecture as follows:
- A service-mesh sidecar can learn the caller’s SPIFFE ID from mutually authenticated TLS and place it in a policy request. section 11.1.2
- An SVID carries the identity as an X.509 certificate or JWT, allowing the workload to prove the named identity. section 11.1.2
- The policy enforcement point preserves additional facts, such as employee, tenant, action, resource, sensitivity label, and runtime context. section 11.1.2
- Mutual TLS suits controlled internal service calls; signed tokens provide verifiable provenance when browser, SaaS, or OAuth-based integrations cannot use mutual authentication. section 12.5.2
Example workload identifier
A documentation service might present the SPIFFE ID spiffe://acme.example/customer-collaboration/docs-service. A proxy can use the authenticated identity as the principal while Cedar separately evaluates whether that service may perform a requested action. section 11.1.2
