Interview › Istio & Service Mesh
How do you debug mTLS handshake failures between two services?
Istio & Service Mesh · Intermediate level
Answer
To debug mTLS handshake failures, I verify both workloads are in the mesh, check PeerAuthentication mode, inspect DestinationRule TLS settings, confirm certificates and trust domains, and read proxy logs for TLS or authentication errors.
Technical explanation
Common causes include one side not injected, STRICT mode with plaintext caller, wrong DestinationRule TLS mode, trust-domain mismatch, expired certificates, or traffic bypassing Envoy.
The source proxy must have the right cluster TLS configuration, and the destination proxy must have valid workload certificates.
Use tls-check and proxy-config secret before changing application code.
Hands-on example
Commands:
$ istioctl authn tls-check deploy/client -n app
$ istioctl proxy-config secret deploy/client -n app
$ istioctl proxy-config cluster deploy/client -n app | grep backend
$ kubectl logs deploy/client -c istio-proxy -n app | grep -i tls
If STRICT is enabled and client has no sidecar, the fix is onboarding the client or scoping policy.
Check how well your resume matches the role with our free resume checker— match score, ATS check, and the skills you're missing.
More Istio & Service Mesh interview questions
- What is Istio, and what are the core capabilities it provides?
- What is the difference between the Istio control plane and data plane?
- What is istiod, and what does it do?
- What is Envoy, and what role does it play in Istio?
- What is the sidecar pattern, and how does Istio inject the proxy?
- How does automatic sidecar injection work (namespace label, webhook)?
- What is the Istio ambient (sidecarless) mode, and how does it differ from sidecar mode?
- What is the difference between ztunnel and a waypoint proxy in ambient mode?