How a service mesh enables automatic mTLS

WHAT THIS TESTS Whether you grasp that mTLS is mutual, both peers authenticate, and that the mesh automates certificate issuance and rotation so applications stay unaware.

A GOOD ANSWER COVERS The control plane runs or fronts a certificate authority. Each workload's sidecar obtains a short-lived leaf certificate encoding the workload identity, derived from its Kubernetes service account, often expressed as a SPIFFE identity. When service A makes its first request to service B, the application sends a plaintext call to its local sidecar. A's sidecar initiates a TLS handshake to B's sidecar. During the handshake each side presents its certificate; A verifies B's cert chains to the mesh CA and that its identity matches the expected destination, and B simultaneously verifies A. Once both are authenticated, a symmetric session encrypts the channel and the request is forwarded to B's application over localhost. Certificates rotate automatically on a short cadence, limiting blast radius if one leaks.

COMMON WRONG ANSWERS Saying the application code manages certificates or terminates TLS; the sidecars do this. Describing only server authentication, which is ordinary TLS, not mutual. Forgetting identity verification and treating mTLS as mere encryption; the authentication of both peers is the point and is what enables identity-based authorization policies.

LIKELY FOLLOW-UPS What identity does the cert carry and how is it bound to a service account? How are certificates rotated and the CA root protected? What is the difference between permissive and strict mTLS modes during migration? How does mTLS interact with AuthorizationPolicy that allows or denies by source identity?

ONE CONCRETE EXAMPLE The checkout sidecar holds a cert identifying it as the checkout service account in the shop namespace. When checkout calls payments, the two sidecars handshake; payments confirms the peer identity is checkout and that it chains to the mesh CA, checkout confirms payments likewise, and only then does encrypted traffic flow. An AuthorizationPolicy can now allow only that verified checkout identity to reach payments.