Security Architecture: Scenario-Based Questions

Mutual TLS (mTLS) ensures that both the client and server authenticate each other during a TLS handshake. It’s widely used in service mesh architectures and zero-trust environments to secure internal traffic.

🔐 mTLS Overview

• TLS: Secures transport channel via server certificate validation.
• mTLS: Both parties present certificates — mutual authentication.
• Benefits: Encrypts traffic, prevents spoofing, adds identity assurance.

🏗️ Key Components

• Certificate Authority (CA): Issues and rotates trusted certificates.
• Client/Server Certs: Contain identity (e.g., SPIFFE URI, DNS).
• Sidecars: In service meshes, proxy (Envoy) terminates TLS for services.

🧰 Implementing mTLS

• Service Mesh: Istio, Linkerd, Consul provide automatic mTLS and policy controls.
• Manual mTLS: Apps use TLS libraries (OpenSSL, gRPC TLS config) with client/server keys.
• Certificate Rotation: Automate renewals using cert-manager, Vault, or mesh integrations.

✅ Best Practices

• Use short-lived certificates and automate provisioning.
• Audit traffic logs for TLS handshake success/failure.
• Enforce policies like “service A can only call service B”.
• Restrict plaintext traffic — enforce mTLS by default in internal mesh.

🚫 Common Pitfalls

• Hardcoding certificates in code or containers.
• Using long-lived certs without rotation mechanism.
• Allowing fallback to non-mTLS for internal APIs.

📌 Final Insight

mTLS is a foundational building block for zero-trust security. While complex to set up manually, service meshes make it almost plug-and-play — giving you encrypted, authenticated, and policy-enforced internal traffic.