mTLS for Service-to-Service
mTLS gives strong service identity, encrypts in transit, and removes whole classes of internal-network attacks. Make it boring with a service mesh or SPIFFE.
Deep dive
Why mTLS internally
Network segmentation alone assumes the network is trusted — that assumption is dead. mTLS gives you cryptographic identity per workload, regardless of where it runs.
Cert lifecycle
Short-lived certs (hours) rotated automatically. Long-lived certs become operational liabilities. SPIFFE/SPIRE or a mesh's built-in CA handles this.
Don't roll your own
Use a mesh (Linkerd, Istio, Cilium) or SPIFFE. Hand-managed PKI is a graveyard project.
Real-world example
From productionBank-grade security mandate: encrypt all internal traffic and prove identity. Linkerd was deployed with auto-mTLS in two sprints; opt-in for sensitive namespaces first, then default-on. Operational lift: minimal after initial config.
Interview questions
1 senior-levelQ1Why bother with mTLS if traffic is internal?▾
'Internal' is no longer trustworthy — supply chain attacks, compromised pods, misconfigured network policies. mTLS gives cryptographic per-workload identity that's enforceable regardless of network path. It also makes audit/compliance straightforward.
Common mistakes
Manual cert management.
Long-lived certs that nobody knows when to rotate.
Trade-offs
Mesh adds CPU/latency overhead — measure on a real workload before committing.