Security: Mutual TLS (mTLS)

Trust No One on the Internal Network

In a typical cloud deployment without a service mesh, traffic between microservices travels unencrypted inside the cluster. The assumption is that the internal network is "safe." This assumption is dangerous: if an attacker compromises any single pod or gains access to the network (via a misconfigured load balancer, a compromised node, or a supply chain attack), they can read all internal traffic with a simple packet sniffer.

Service meshes solve this by enabling Mutual TLS (mTLS) transparently across all service-to-service communication.

You are probably familiar with regular TLS — it is what happens when your browser connects to https://yourbank.com. Your browser verifies the bank's certificate to confirm it is talking to the real bank. The bank does not verify who you are at the TLS layer (that happens at the application layer with a username and password).

Mutual TLS adds the reverse verification:

1. Service A initiates a connection to Service B.
2. Service B presents its certificate. Service A verifies it is legitimate.
3. Service A also presents its own certificate. Service B verifies that A is who it claims to be.
4. Only if both verifications pass does an encrypted tunnel open.

The service mesh handles all of this automatically. When a pod starts, the mesh agent (istio-agent in Istio) requests a certificate from the control plane's built-in Certificate Authority. The CA issues a short-lived certificate (often valid for only 24 hours) and the agent stores it in memory. The Envoy sidecar uses this certificate for all mTLS handshakes. When the certificate nears expiry, the agent automatically rotates it — no human intervention, no downtime.

Short certificate lifetimes are a deliberate security design. If a private key is somehow stolen, it becomes useless within hours rather than years.