Sidecar Interception Boundary
also called Mesh Coverage Boundary, Proxy Capture Scope
The precise set of traffic a sidecar proxy actually sees and can secure, which is narrower than "all traffic from this pod" and is what decides whether a mesh's guarantees apply to a given call.
A mesh is sold as encryption and policy without code changes. What it delivers is encryption and policy for the traffic the proxy intercepts, terminating at another proxy. Those two conditions define a boundary, and every mesh incident that surprises a team happens on the far side of it.
The mechanism is mundane. An init container rewrites the pod's iptables rules so outbound connections on captured ports are redirected into the local proxy. The proxy consults the mesh's service registry, and if the destination is a registered workload with an identity, both proxies perform a mutual TLS handshake. If the destination is not a mesh member, the proxy forwards the connection as the application wrote it. Plain HTTP in, plain HTTP out.
Why it matters
The dashboard says 100% mTLS and it is telling the truth about a denominator that excludes exactly the traffic an auditor cares about: calls that leave the cluster. A payments API, an email provider, an object store on its public endpoint, a partner's webhook. These are the connections carrying credentials to third parties, and they are the ones the mesh never touched.
The boundary also decides where policy applies. An authorisation policy that denies traffic between two services is enforced by the receiving proxy. A workload with no proxy is not subject to it at all, which turns an unlabelled namespace into a policy bypass that nobody wrote down.
Implementation patterns
- An egress gateway as the only route out. All outbound traffic is directed through a small set of proxies that do have identity, TLS origination and policy. This converts "which services talk to the outside world" from an audit into a query, and gives one place to alert on plaintext by destination port.
- TLS origination at the gateway or in the client library, so the encryption of external calls is somebody's explicit responsibility rather than an assumption.
- Namespace labelling enforced by admission control, so a workload cannot be created outside the mesh by omission. This closes the most common gap.
- Explicit port exclusions, reviewed. Most meshes exclude some ports by default and allow annotations to exclude more. Every exclusion is a hole; each should have a reason recorded.
- A periodic packet capture at the node or gateway, matching on plaintext credentials patterns, as a detection of last resort.
Industry example
Lyft built Envoy and open-sourced it in 2016 precisely to move retries, timeouts, telemetry and TLS out of application code and into a uniform proxy, which is what makes the model attractive at scale. The same design that makes the proxy transparent to the application is what makes its boundary invisible: nothing in the application changes when a call falls outside the mesh's coverage, so nothing signals it.
Failure scenarios
- Credentials to an external SaaS sent in plaintext while the compliance dashboard reports full mTLS.
- A CronJob or DaemonSet without injection calling an internal service, unauthenticated, and being allowed because the receiving policy only sees mesh peers.
- A port excluded for a database driver that also carries application traffic, silently uncovered.
- Traffic to a raw IP address that the registry cannot map to a service, routed as pass-through and exempt from policy.
- Permissive mode left on after migration, so any non-mesh client can still reach services that believe they require mTLS.
Trade-offs
| Choose | Gains | Pays |
|---|---|---|
| Wide interception (all ports, all namespaces) | Fewer gaps, simpler mental model | Breaks protocols the proxy mishandles; every new workload must tolerate the proxy |
| Narrow interception with an egress gateway | External traffic is explicit and controllable | A central gateway to run and scale, and an extra hop on outbound calls |
| No mesh, TLS in client libraries | No proxy cost or blast radius | Per-language implementation, and certificate rotation becomes a project |
When not to use it
If a platform has fewer than roughly 20 services in one language, the mesh's boundary problem is a cost with no matching benefit: certificate handling in a shared client library covers the same ground with one failure domain instead of two. Adopt the mesh when per-service implementation of identity, retries and telemetry is the larger cost, and even then treat its coverage as a thing to verify rather than assume.
Interview question
Q: Your compliance dashboard reports 100% mTLS across the mesh. An auditor asks you to prove that no credentials leave the cluster in plaintext. What do you actually have to show, and what would you build if you cannot show it?
What a strong answer covers: that the dashboard's denominator is mesh-to-mesh traffic · that external destinations have no peer proxy, so the sidecar is a pass-through · the four common gaps (excluded ports, uninjected workloads, raw IP destinations, permissive mode) · an egress gateway with plaintext alerting as the control that makes the claim provable · and the point that the proof is a property of the egress path, not of the mesh.
Quick check
Quiz: A service in the mesh calls an external payments API over HTTP. Is the traffic encrypted? No: mTLS requires a proxy at both ends, and an external endpoint has none, so the sidecar forwards the connection exactly as the application opened it.
Flashcard: Which traffic does a sidecar not protect? Anything whose far end has no peer proxy: external endpoints, excluded ports, uninjected pods and raw-IP destinations.