Problem
Service-to-service auth typically uses shared secrets (API keys) or nothing. Secrets leak, rotation is hard, no identity verification.
security-complianceestablished · medium operational burden
Mutual TLS (mTLS)
Also known as: mutual-tls, mtls, service-mesh-mtls, certificate-based-auth
Intent
Authenticate both client and server in every connection using certificates, enabling zero-trust service-to-service communication.
Forces
- •Services must verify each other's identity
- •Certificate rotation must be automatic, frequent
- •No application code changes for auth
- •Performance: TLS handshake overhead minimal
Solution
✓ When to Use
- •Service-to-service communication in zero-trust
- •Regulatory: encryption in transit required
- •Multi-cluster, hybrid cloud
✗ When Not to Use
- •External APIs (clients can't do mTLS easily)
- •Legacy services that can't terminate TLS
- •Simple architectures where shared secrets suffice
Pros
- +Strong identity: cryptographic, not secret-based
- +Automatic rotation: no manual secret management
- +Encryption in transit: free with auth
- +Standard: SPIFFE, X.509, TLS 1.3
Cons
- −Certificate lifecycle: issuance, rotation, revocation
- −Clock skew breaks validation
- −Debugging: encrypted traffic, need keys
- −Performance: handshake overhead (mitigate: session resumption)
Cost Profile
Infrastructure
Low (service mesh) to Medium (PKI, CA)
Operational
Medium — cert rotation, CA health, trust domain
Cognitive
Medium — PKI concepts, SPIFFE
Failure Modes
CA down → no new certs → rotation fails → outage
Clock skew → cert validation fails → connection refused
Revocation not checked → compromised cert still works
SPIFFE ID mismatch → authorization fails silently
TLS version mismatch → handshake failure
Real-World Examples
Alternatives
- api-keys
- jwt
- oauth2
- shared-secret
- ip-allowlist
Related Patterns
- service-mesh
- zero-trust
- spiffe
- api-gateway
- workload-identity
Competency Domains
security compliancedistribution communicationreliability opseconomics evolution