Home / Knowledge hub / Service mesh
Knowledge hub
Service mesh
A layer that handles encryption and identity between services in a cluster.
What it means
A service mesh is a layer of small proxies, or a shared node component, that sits alongside your services and handles their communication. Services in a cluster talk to each other through it, and it can encrypt that traffic, check who is calling and enforce rules about who may talk to whom.
Istio and Linkerd are well-known examples. The idea is to move this work out of each application, so developers do not write encryption and identity code in every service. The mesh does that work in one place, for all of them, and the application code stays focused on the product itself. Operators then change the rules without redeploying every service.
Why it matters
Inside a cluster, traffic between services is often plain and unauthenticated. If an attacker gets a foothold in one pod, they can reach many others. A mesh can give each service its own identity, encrypt calls with mutual TLS and refuse connections the policy does not allow, which limits lateral movement.
It supports a zero trust approach inside the network: no service is trusted just for being in the cluster. NIST has published guidance on using a service mesh for access control between microservices. Treat it as an inner layer, not the whole defence.
How it shows up
You meet it as sidecar proxies injected next to each pod, or as a node-level component in newer designs. Policies describe which service may call which, on which path and method. It also gives traffic metrics and retries. The mesh enforces them for every call.
Know what it does not do. A mesh checks service-to-service calls, not whether a signed-in customer may see a given record, so your application still needs its own authorisation. Watch for permissive modes left on after rollout, namespaces outside the mesh, and the extra complexity of another thing to patch and configure.
Questions people ask
Service mesh, answered
Do we need a service mesh?
Not for every system. A small number of services may be fine with network policies and good application checks. A mesh pays off as service count grows and you need consistent identity, encryption and policy.
Weigh it against the added complexity.
Is a service mesh the same as an API gateway?
No. A gateway sits at the edge and handles traffic coming in from outside. A mesh handles traffic between services inside. Many systems use both.
They cover different paths.
Does a mesh replace network policies?
They overlap but work at different layers. Network policies filter by address and port at the network level; a mesh checks service identity and can apply rules by path and method.
Many teams use both.
Does mTLS in a mesh protect user data?
It protects the data in transit between services and confirms which service is calling. It does not decide which user may see which record.
That is an application decision.
What goes wrong with meshes?
Permissive mode left on, services running outside the mesh, broad allow-all policies, and slow patching of the mesh itself.
Check that policies are enforced, not just installed.
Related
Terms that sit next to this one
mTLS
A connection where both client and server prove who they are with certificates.
Zero trust
Assuming the network proves nothing, and checking every request.
Kubernetes network policy
Rules that say which pods may talk to which other pods.
Kubernetes
A system that runs and manages containers across many machines.
Lateral movement
Moving from the first thing reached to the things worth taking.
Who may call this service?
A mesh checks services. We test the application itself, including one signed-in account reaching another's data, and report only what we exploited. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.