December 30, 2025
Updated: November 3, 2026
A practical guide to sidecar proxies in Kubernetes and service mesh architectures
Mohammed Khalil
Microservices turn every service-to-service call into a security decision, and a sidecar proxy is one way to make that decision consistently without changing application code. A sidecar proxy is a helper proxy that runs next to each workload, usually in the same Kubernetes pod, and handles that workload's network traffic. In a service mesh it enforces mutual TLS, authorization policy, retries, and telemetry. This guide explains how the pattern works, what it costs, how it compares with Istio's ambient mode, and which misconfigurations security teams should verify.
A sidecar proxy is a network proxy deployed alongside an application instance so that traffic entering or leaving that instance passes through it. The application keeps its own code and sends ordinary requests. The proxy adds the network functions the application would otherwise have to implement itself.
In practice, many meshes, including Istio, use Envoy as the sidecar; Linkerd uses its own lightweight proxy. The Cloud Native Computing Foundation describes Envoy as an open source edge and service proxy designed for cloud-native applications, and it became a CNCF graduated project in November 2018.
The word "sidecar" describes the layout. Like the sidecar on a motorcycle, the proxy is attached to the main vehicle but is a separate component with its own lifecycle, configuration, and resource use.
A service mesh has two parts. The data plane is the set of proxies that carry traffic. The control plane distributes configuration, identity, and policy to those proxies.
In Istio's sidecar mode, an Envoy proxy runs with each pod, and the project says it has used the sidecar pattern since its first release in 2017. The control plane, istiod, pushes routing and security configuration to every proxy.
Mutual TLS depends on each workload having a verifiable identity. In Istio, the identity is tied to the Kubernetes service account. A local Istio agent generates a private key and a certificate signing request, istiod validates the workload's credentials and signs the certificate, and Envoy receives it through the Secret Discovery Service. The agent repeats the process before the certificate expires, so rotation does not depend on application changes.
Kubernetes now has first-class support for the pattern. A native sidecar is declared as an init container with restartPolicy: Always. The Kubernetes documentation states that the feature is stable since v1.33, having first appeared in v1.28.
This matters for proxies because startup order is guaranteed. The kubelet waits for the sidecar to report started before it launches the application container, and it keeps the sidecar running until the application has stopped. A sidecar in a Job's pod also no longer blocks the Job from completing.
Conceptual view of sidecar proxies in a service mesh, based on the sidecar model described in the Istio documentation.
NIST's guidance on building secure microservices with a service mesh (SP 800-204A, May 2020) explains why the pattern is attractive: a mesh can express service-to-service security requirements consistently without modifying each microservice's code. In practice, a sidecar gives a platform team four controls:
A mesh is an internal control. It limits what a compromised or misconfigured workload can reach, but it does not replace application-level authentication, input validation, or patching.
The pattern trades simplicity in application code for complexity in the platform. Istio's own documentation says sidecar mode "comes with a resource cost and operational overhead", and describes sidecar resource planning as wasteful because CPU and memory must be provisioned for the worst case of each individual pod.
Two operational limits are worth planning for:
Ambient mode is Istio's alternative data plane. It uses a per-node Layer 4 proxy for encryption and basic authorization, and an optional per-namespace Envoy "waypoint" for Layer 7 features. Istio documents ambient as production-ready for single-cluster use cases as of Istio 1.22. Its support table also lists limits such as multi-cluster and VM support, so check the current table before choosing it.
The security trade-off is explicit in Istio's comparison: in sidecar mode, a compromised application pod gives access to that pod's mesh keys, while the table lists ambient as "No" for the same row. Ambient instead concentrates keys in the node agent for the workloads on that node.
The following decision aid reflects our assessment of when each option fits. It is a starting point, not a rule.
Situation | Sidecar mode | Ambient mode | No mesh |
|---|---|---|---|
Need mTLS and identity-based policy across many services | Strong fit | Strong fit for single-cluster | Application teams must build it |
Need Layer 7 policy on every workload | Native | Requires a waypoint | Application or gateway only |
Multi-cluster or VM workloads | Documented as stable | Check current support table | Not applicable |
Few services, one team, simple trust boundary | Likely excessive | Likely excessive | Often sufficient |
Strict per-workload key isolation requirement | Weigh key exposure in the pod | Weigh node-level key custody | Not applicable |
Many mesh weaknesses come from configuration rather than from flaws in the proxy itself. The following issues can be checked against the Istio security documentation:
Validation should start with read-only inspection in an environment you own or are explicitly authorized to test. These Kubernetes commands list the mutual TLS and authorization policies that apply across namespaces:
kubectl get peerauthentication -A
kubectl get authorizationpolicy -ACompare the output with your intended trust model. Then confirm that each workload that should be in the mesh actually has a proxy container, and that workloads outside the mesh are documented exceptions.
The next step is behavioral testing: attempting connections from a pod that should be denied, and from a namespace outside the mesh, in a lab or approved test window. This is where a Kubernetes penetration test adds value, because the question is not whether a policy exists but whether it holds under a realistic attacker's starting position.
A sidecar proxy tends to fit when you run many services owned by different teams, when you need identity-based service-to-service policy, and when platform engineers can operate a mesh. It fits less well for a small system with a single trust boundary, where the added operational surface may exceed the benefit.
Much of the risk in these architectures sits in the API surface between services, so API security statistics are a useful companion read when you size the risk.
Because mesh configuration changes with every deployment, many teams pair design reviews with continuous penetration testing rather than a single annual test.
For clusters that run on a public cloud, the mesh sits alongside identity, networking, and storage controls, which a cloud penetration test reviews as one system.
Teams that build the mesh into their delivery pipeline can also use the DevSecOps statistics to see where application security testing commonly falls short.
A reverse proxy such as NGINX or HAProxy usually sits at a central point, such as in front of a server or at a cluster edge, and serves many applications. A sidecar proxy runs beside each application instance and is managed as part of a fleet by a control plane. It focuses on service-to-service traffic, while a gateway focuses on traffic entering the cluster.
In a classic sidecar mesh, every workload that participates has its own proxy. Workloads can opt out, but they then communicate outside the mesh's controls. Istio's ambient mode avoids a proxy per pod by using a per-node proxy, with an optional waypoint for Layer 7 features.
Each sidecar consumes CPU and memory and adds a hop to each call. Istio's documentation lists average p90/p99 latency of 0.63 ms to 0.88 ms for sidecar mode, but does not state its test conditions. Measure your own services under realistic load before deciding.
In Istio, a local agent generates a key and certificate signing request, istiod validates and signs it, and Envoy receives the certificate through the Secret Discovery Service. The agent renews it before expiry. Proxies then use the certificates to authenticate each other during a mutual TLS handshake.
The service instance usually cannot send or receive mesh traffic until the proxy recovers, because the proxy carries its traffic. Kubernetes restarts a failed sidecar container as part of normal pod behavior. Size proxy resources for peak load, and monitor proxy health as a first-class signal.
Proxies normally listen on pod-local or cluster-internal interfaces, so an external attacker usually needs a foothold first. The more realistic risks are a compromised workload that abuses a permissive policy, a vulnerable proxy version, or a misconfigured control plane. Keep the mesh patched and review policies regularly.
No. The pattern predates Kubernetes and can be used wherever a proxy runs beside a service, including on virtual machines. Kubernetes makes it convenient through pods and automatic injection, which is why it is most visible there.
A sidecar proxy gives a platform team a consistent place to enforce encryption, identity, authorization, and observability for service-to-service traffic. The benefit is real, but so are the costs: extra resources, a larger operational surface, and security that depends on configuration being correct. Choose the data plane that matches your trust model, move mutual TLS to strict mode once clients are ready, and write explicit authorization policies instead of relying on defaults. Then test the mesh from an attacker's perspective, because a policy that exists is not the same as a policy that holds.
If you want an independent review of how your mesh behaves under attack, you can discuss scope with DeepStrike's team.
Stay secure with DeepStrike penetration testing services. Reach out for a quote or customized technical proposal today
Contact Us