A service mesh is an infrastructure layer for microservices that manages service-to-service communication without requiring changes to service code. It uses sidecar proxies deployed alongside service instances to intercept inbound and outbound traffic. The proxies can handle routing, load balancing, service discovery, security, and telemetry while leaving business logic in the services themselves. section 4.5.1
For authorization, a mesh places a policy enforcement point (PEP) at every internal hop rather than only at an API gateway. This matters when east–west traffic—calls among internal services—does not pass through the gateway. A local sidecar can authenticate the calling workload with mutual TLS (mTLS), gather service identity and request context, request an authorization decision, and forward the call only when permitted. section 11.1.2 section 11.0
A mesh-based enforcement path separates responsibilities across the request flow:
- A calling service sends a request through its local sidecar proxy. section 11.1.2
- The sidecar establishes mTLS and identifies the calling workload. section 11.1.2
- The sidecar acts as a PEP, converts available identity and request data into a normalized authorization request, and asks a policy decision point (PDP) for a decision. section 11.1.2
- The sidecar forwards allowed requests and blocks denied requests, making policy enforcement consistent across internal components. section 11.1.2 section 11.1.4
Blocking sensitive documents from indexing
A Docs service can send documents to a Search service through sidecars. The Docs sidecar asks Cedar whether the Docs workload may perform the document-index action. A policy permits indexing by default but denies it when a document’s sensitivity is Legal. Ordinary documents are forwarded to Search; Legal documents are stopped before indexing. section 11.1.2 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.
The diagram traces a sidecar-enforced Docs-to-Search request and shows how the authorization decision distinguishes Legal documents from other documents. section 11.1.2
A service mesh is not a replacement for an API gateway or every local proxy. Gateways centralize enforcement for edge traffic, while mesh sidecars protect most internal calls. Per-service proxies can cover legacy or transitional APIs that have not entered the mesh. All three approaches can share one policy model: normalize the request, evaluate it, enforce the result, and log the protected action. section 11.1.4 section 11.1
The main tradeoff is operational placement. Embedded application enforcement can use full application context for highly specific decisions, but is harder to update uniformly. A mesh offers consistent service-level enforcement without modifying core applications, but its value depends on routing internal calls through sidecars and operating the mesh infrastructure. section 4.5.1 section 11.1.4
