Encryption in transit & service-mesh mTLS
TLS everywhere, mesh identity, and short-lived cert rotation.
Encrypting the edge and trusting the internal network is a decades-old habit that modern architectures cannot afford. Once an attacker is inside the perimeter, plaintext east-west traffic is theirs to read and tamper with. Encryption in transit everywhere — including service-to-service — plus mutual authentication is what actually enforces a zero-trust data plane.
TLS everywhere, including east-west
Terminating TLS at the load balancer and letting the internal hop run plaintext leaves every service-to-service call exposed inside the trust boundary. Push encryption all the way to the workload. A service mesh makes this practical: sidecar proxies transparently wrap every connection in TLS without changing application code, so even a flat internal network carries no cleartext traffic.
# Istio: require mutual TLS for every workload in the namespace.apiVersion: security.istio.io/v1kind: PeerAuthenticationmetadata:name: defaultnamespace: paymentsspec:mtls:mode: STRICT # plaintext connections are refused, not just upgraded# AuthorizationPolicy then decides WHICH identity may call — authn + authz:apiVersion: security.istio.io/v1kind: AuthorizationPolicymetadata: { name: allow-checkout, namespace: payments }spec:selector: { matchLabels: { app: ledger } }rules:- from:- source:principals: ["cluster.local/ns/payments/sa/checkout"]
Identity-based mTLS and rotation
Mutual TLS means both ends present a certificate, so a service proves who it is, not merely that it is on the network. The strong version binds those certificates to a workload identity — a SPIFFE ID like spiffe://cluster.local/ns/payments/sa/checkout — issued by the mesh CA and rotated automatically on a short lifetime. Because certs are minted and rotated by the platform, there is no long-lived key to steal and no manual renewal to forget; a revoked or expired identity simply stops being able to connect.