Distributed services need authenticated, encrypted communication without making every application implement the same security controls. A service mesh moves this work into infrastructure: it secures internal service-to-service traffic with mutual TLS (mTLS), verifies service identity, and applies shared authorization rules outside application code. section 16.4 section 16.5
A protected internal call
When an inventory service calls another microservice, sidecars placed beside both services can encrypt the connection, authenticate each service, and enforce authorization rules transparently. The applications do not need to implement those transport controls themselves. section 3.1.2 section 16.4
Use the mesh as part of a layered service-authorization design:
- Secure east-west traffic between internal services with automatic mTLS and consistent identity checks. section 16.4 section 16.5
- Keep the API gateway at the system boundary for external, north-south requests; use it to check tokens and block unauthorized traffic. section 16.4
- Retain detailed business authorization in the application, while infrastructure enforces baseline identity and access consistently. section 16.5
This arrangement reduces duplicated security code and human error, but it adds setup complexity and cannot express every business rule. Responsibility should follow team ownership: platform teams can manage shared infrastructure, while application teams keep service-specific decisions. section 16.4 section 16.5
