liveBook · Manning

Workload identity

As explained in Authorization in Action

A workload identity is the identity of a service or process making a request on behalf of a principal.

A workload identity identifies the service or process making a request on behalf of another principal. In service-to-service authorization, it proves which service is calling, while policy may also require the initiating principal, tenant, sensitivity label, and delegation context. section 11.1.2

Filtering a document before indexing

A Docs service workload identity requests doc:index for a document on behalf of Carol. The request includes tenant and sensitivity context. A Cedar policy denies documents marked Legal, so the service-mesh sidecar blocks the request before it reaches Search. This prevents Search from receiving unauthorized data and limits the risk of Docs acting as a confused deputy. 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.

Use the enforcement diagram to trace how sidecars verify service identity and apply Cedar policy at each service hop. section 11.1.2

How Authorization in Action covers it

How deep it goes
Demonstrates identity alongside principal, tenant, sensitivity, and delegation context, then applies the combination through Cedar.
Examples
Uses a Docs-to-Search indexing request where Cedar denies documents classified as Legal.
What you can do after
Apply it via Cedar and sidecar enforcement to authorize service calls before they reach downstream services.
How it connects
Connects workload identity to service mesh, sidecar enforcement, Cedar, zero trust, delegation, and confused deputy prevention.

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Authorization in Action. The section links point to the parts of the book it draws on.