A sidecar process is a separate proxy or component deployed beside a service, usually in the same pod, container environment, or virtual machine. It handles cross-cutting work without changing the service’s core code. In a service mesh, injected sidecar proxies intercept inbound and outbound traffic, making routing, security, telemetry, and policy enforcement infrastructure responsibilities rather than application responsibilities. section 4.5.1
For authorization, a sidecar acts as a Policy Enforcement Point (PEP). At every internal service-to-service hop, it can authenticate the calling workload with mutual TLS (mTLS), collect service identity and request context, send a normalized authorization request to a Policy Decision Point (PDP) such as Cedar, and forward the call only when policy permits it. This closes east–west traffic gaps that an edge API gateway may not see. section 11.1.2
Protecting document indexing
When a Docs service sends documents to Search for indexing, the Docs sidecar constructs an authorization request for each outbound call. A policy can allow the Docs workload to perform the indexing action while denying documents whose sensitivity is Legal. Enforcement therefore follows the request between internal services, not merely the original dashboard request at the system edge. section 11.1.2 section 11.1.2
Choose a sidecar-based enforcement pattern when its tradeoffs fit the architecture:
- Use it to apply a consistent authorization check to each internal hop without modifying each service. section 11.1.2
- Use it where workload identity, encrypted service communication, and request-level policy checks are needed together. section 11.1.2
- Compare it with an API gateway for incoming edge traffic and a per-service proxy for APIs not ready to join the mesh. section 11.1.4
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.
The diagram shows sidecars placing Cedar evaluation directly on the Docs-to-Search path, with a classification-based deny rule applied before indexing. section 11.1.2
A sidecar provides broad, local enforcement coverage, but it is an architectural deployment choice rather than a new policy model. Gateway, mesh, and per-service proxy patterns can all normalize requests, evaluate the same authorization policies, enforce the result, and log protected calls; they differ mainly in request coverage, context, deployment mechanics, and operational complexity. section 11.1 section 11.1.4
