Zero Trust requires that every connection between services be authenticated and encrypted. The mechanism for this is mTLS — but to understand mTLS, you first need to understand standard TLS.
Standard TLS: One-Way Trust
When your browser connects to https://bank.com, it uses TLS (Transport Layer Security) to establish an encrypted channel. The handshake works like this:
- The bank's server presents a digital certificate — a cryptographically signed document that says "I am bank.com, and a trusted Certificate Authority (CA) vouches for this."
- Your browser verifies the certificate against its list of trusted CAs.
- An encrypted session is established.
This is one-way authentication: the client (your browser) verifies the server's identity, but the server has no cryptographic proof of who the client is. It just knows a connection arrived. For public websites, this is fine — you want anyone to be able to visit your site.
Mutual TLS (mTLS): Two-Way Trust
In a Zero Trust microservices architecture, a database should not accept a connection just because it arrives from an "internal" IP address. It needs cryptographic proof of which specific service is calling.
mTLS (Mutual TLS) extends the standard TLS handshake by requiring both parties to present and verify certificates:
- The server presents its certificate to the client. The client verifies it.
- The client presents its own certificate to the server. The server verifies it.
- Only if both verifications succeed does the encrypted session begin.
Here is what this looks like in practice. Suppose payment-service wants to connect to payment-db:
payment-service payment-db
| |
|--- "Here is my cert: I am |
| spiffe://acme.com/payment" -----> |
| | [Verifies cert against trusted CA]
| | [Checks: is this SPIFFE ID allowed?]
| <--- "Here is my cert: I am |
| spiffe://acme.com/db" --------- |
| [Verifies cert against trusted CA] |
| |
|====== Encrypted session begins ======|
If an attacker compromises a different pod on the same cluster network and tries to connect to payment-db, the connection is rejected immediately — the attacker's pod has no valid certificate signed by the trusted CA, and no certificate with the right SPIFFE ID.
The Critical Difference from Network-Level Controls
A firewall rule says "allow traffic from IP 10.0.1.0/24." mTLS says "allow traffic from the entity holding a certificate with identity spiffe://acme.com/payment." The first is a location-based check that any process on that subnet can pass. The second is a cryptographic identity check that only the legitimate payment service can pass. This is the essence of Zero Trust applied to service-to-service communication.
Interviewers frequently ask: "What is the difference between TLS and mTLS, and when would you use each?" The key answer: standard TLS authenticates only the server (suitable for public-facing services where any client should connect). mTLS authenticates both parties (required for service-to-service communication in a Zero Trust model where you need to know exactly which workload is calling). A follow-up question is often: "What happens if a certificate is compromised?" — the answer is that short-lived certificates (rotated every hour or less) minimize the blast radius, which is exactly what SPIRE provides.