How a service mesh enables automatic mTLS
identity and the data-plane handshake.
the control plane issues short-lived workload certificates, sidecars present them, both sides verify identity and encrypt the channel.
What's really being asked
Whether you grasp that mTLS is mutual, both peers authenticate, and that the mesh automates certificate issuance and rotation so applications stay unaware.
The full answer
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.
The mistakes people make
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.
What usually comes next
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?
A 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.
Interview question
What distinguishes the mTLS a service mesh provides from the ordinary one-way TLS a browser uses with a website?
- a.The application code, not the sidecar, performs the handshake
- b.Mesh mTLS skips encryption and only checks identity
- c.Only the calling service presents a certificate; the server does not
- d.Both client and server present and verify certificates, authenticating each otherCorrect
Why? this is the answer
Mutual TLS authenticates both peers: each sidecar presents and verifies a certificate against the mesh CA. One-way TLS authenticates only the server, and in a mesh the sidecars, not the app, handle the handshake.
Just read this? Test yourself on what you have been reading.
Read the original → linkerd.io
- #service-mesh
- #mtls
- #security
- #linkerd
- #istio
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles