Meshes, mTLS and invisible proof
A service mesh encrypts and measures traffic between services without touching their code, which also means you can't tell from the app whether it's working. Learn where the proof lives.
Inside a cluster, services call each other constantly. By default that traffic is plain, unencrypted and unmeasured, and any pod can call any other. A service mesh puts a layer of infrastructure underneath every call. It gives you:
- mTLS: every connection is encrypted, and both sides prove who they are with certificates the mesh issues and rotates. No application code changes.
- Telemetry: who called whom, how often, and how fast.
- Policy: rules like “only the frontend may call the payments service”.
The tilt platform runs Istio in ambient mode. Istio’s original sidecar mode, which it still supports, injects a proxy into every pod. Ambient mode uses a shared per-node proxy called ztunnel for encryption and connection-level telemetry, and optional waypoint proxies for request-level features such as HTTP routing and request counts. Lab 06 adds a waypoint for exactly that reason: ztunnel encrypts and forwards traffic but doesn’t count requests.
The catch: it’s invisible
Because the app doesn’t change, the app can’t tell you whether it’s in the mesh. When the tilt platform was first built, zero namespaces carried the label that enrolls workloads. ztunnel ran on every node and every check was green, and not one workload was in the mesh. Kiali’s mesh view was the only thing that showed it.
Configured-but-inert is worse than absent, because it reads as protection.
How you join, and how you prove it
You enroll a namespace by labelling it istio.io/dataplane-mode=ambient. The proof is on the pod, not the namespace:
kubectl -n hello get pod -l app.kubernetes.io/name=hello \
-o jsonpath='{.items[0].metadata.annotations.ambient\.istio\.io/redirection}'
# enabled -> traffic is captured by ztunnel
# (empty) -> not in the meshYour app works exactly the same with and without the mesh. How do you prove a pod is in the ambient mesh?
The label is the request and the annotation is the result. The platform once had ztunnel running everywhere and no workload enrolled. Only the mesh's own view showed it.
What does mTLS add over ordinary TLS?
With ordinary TLS only the server proves its identity. Mutual TLS makes the client prove its identity too, which is what makes 'only the frontend may call payments' enforceable.
In ambient mode, which component would you add to get per-request metrics such as HTTP success rate?
ztunnel handles encryption and connection telemetry. Request-level (L7) features live in waypoints, which is why Flagger in lab 06 needs one to read a success rate.
Everything above ran in your browser. Now do it on a real cluster with tilt lab 03-join-the-mesh (profile observability). You need Docker, kind and Tilt, about 15 GB of free disk and 8 GB of spare RAM. Setup guide · Can my machine run it?
# Kiali: https://kiali.localhost -> Overview, note "Data planes (N)"
kubectl label ns hello istio.io/dataplane-mode- # leave the mesh
kubectl -n hello rollout restart deploy/hello
kubectl -n hello get pod -l app.kubernetes.io/name=hello -o jsonpath='{.items[0].metadata.annotations.ambient\.istio\.io/redirection}'
kubectl label ns hello istio.io/dataplane-mode=ambient --overwrite
kubectl -n hello rollout restart deploy/hello
./scripts/platform.sh lab 03Sources
Missions and quizzes above earn their own XP. This marks the lesson done.