Service mesh architecture
Sidecar vs ambient; what the mesh enforces.
A service mesh is the most common way to bring workload identity, mTLS, and authorization to a cluster without changing application code. Understanding its architecture is what lets you reason about where security is enforced and what it costs.
Proxies that own the security
A mesh interposes a proxy in the path of every service’s traffic. In the sidecar model (classic Istio, Linkerd) an Envoy or linkerd2-proxy runs alongside each pod and transparently wraps outbound connections in mTLS and enforces policy on inbound ones — the application sends plain HTTP to its own proxy and the proxy handles identity and encryption. In the newer ambient model, that work moves to a per-node component (ztunnel), removing per-pod sidecars and their overhead while keeping the same mTLS and identity guarantees. Either way, the app is unchanged and the mesh owns the cryptography.
# Sidecar model — a proxy per pod:# [ app ] --plain--> [ sidecar ] ==mTLS==> [ sidecar ] --plain--> [ app ]# frontend proxy proxy api# the app never sees TLS; the proxies authenticate + encrypt.## Ambient model — per-node ztunnel handles mTLS, no sidecar in the pod.## Enable the mesh by labeling a namespace for injection:kubectl label namespace prod istio-injection=enabled
What the mesh gives you
Because the proxy sits in every connection, the mesh delivers three zero-trust primitives uniformly across polyglot services: identity (each workload gets a SPIFFE-style certificate), encryption (mTLS between proxies), and authorization (identity-based policy at the proxy). It also provides observability — a map of who talks to what — which is invaluable for writing tight policy and investigating incidents. The tradeoff is operational complexity and some latency/resource overhead, which the ambient model aims to reduce. Istio and Linkerd are the dominant choices; Linkerd favors simplicity, Istio favors feature breadth, but both anchor identity in the workload’s Kubernetes service account.