What is the Mutual TLS (mTLS) pattern for service-to-service authentication?

Mutual TLS (mTLS) extends standard one-way TLS by requiring both sides of a connection to present and verify X.509 certificates. In a microservices context it provides two things simultaneously: an encrypted channel (confidentiality and integrity) and verified service identity (authentication) — without any application-level token or API key. The services prove who they are via their certificates, issued by a trusted internal Certificate Authority.

Standard TLS vs mTLS:

• Standard (one-way) TLS — only the server presents a certificate. The client verifies the server's identity but the server does not verify the client. Used for browser-to-server HTTPS.
• mTLS — both client and server present certificates. Each side verifies the other's certificate against a shared CA. This proves the client is a legitimate service instance, not just any caller that can reach the network.

# Istio PeerAuthentication — enforce STRICT mTLS in a namespace
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT     # reject any plaintext or one-way TLS traffic
---
# Istio automatically rotates certificates via its Citadel CA.
# Envoy sidecars handle the TLS handshake transparently.
# Application code sees plain HTTP internally — zero code changes.

In a service mesh (Istio, Linkerd), mTLS is fully transparent to application code: the sidecar proxy handles the TLS handshake using certificates provisioned by the control-plane CA. Certificates are short-lived (e.g., 24 hours) and rotated automatically, eliminating the risk of a compromised long-lived credential.

mTLS is the recommended pattern for east-west (service-to-service) authentication within a cluster. It replaces shared API keys and static secrets with cryptographic identity tied to a specific service workload.