When a Docs service calls Search, the receiving infrastructure must know which workload is calling before authorization evaluates the request. An SVID, or SPIFFE Verifiable Identity Document, gives that workload cryptographic proof of its SPIFFE identity. section 11.1.2 section 12.5.2
SPIFFE can represent an SVID as an X.509 certificate or JWT. Service-mesh proxies use it to establish mutually authenticated TLS, extract the authenticated workload identity, and pass it to the policy enforcement point. The SVID proves which workload is calling; the policy engine still decides whether the requested action is allowed. section 11.1.2 section 12.5.2
SVIDs support an authorization architecture by:
- Authenticating software workloads such as services, jobs, containers, functions, or agents. section 11.1.2
- Providing a trustworthy principal signal for a policy request while preserving other context, including employee, tenant, action, resource, and runtime facts. section 11.1.2
- Supporting internal service-to-service calls where both endpoints can use mutual TLS; signed tokens address integrations where mTLS is less practical. section 12.5.2
A workload identity in practice
A sidecar can authenticate Docs through mTLS, identify it with a URI such as spiffe://acme.example/customer-collaboration/docs-service, and include that identity as the principal in a request to the policy decision point. Cedar can then allow document indexing except for documents classified as Legal. section 11.1.2
Figure 11.2 Service mesh enforcement with sidecars. Cedar evaluates each document sent from Docs to Search. Documents tagged "Legal" are denied; others are allowed.
Shows sidecar enforcement, workload authentication, and policy evaluation as separate but connected steps. section 11.1.2
