> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Sidecar
> Describes Envoy sidecars in Istio, Sidecar resources for ingress and egress control, and PeerAuthentication for mTLS enforcement with practical examples.
A sidecar proxy (for example, Envoy) is injected into application pods to manage and secure traffic for workloads in the Istio service mesh. Envoy provides secure connections, observability, and advanced traffic-management capabilities such as load balancing, retries, circuit breaking, and mirroring.
When Istio automatic sidecar injection is disabled for a namespace, workloads there do not receive an Envoy proxy and therefore do not benefit from sidecar features. Traffic can still flow unless you apply policies (for example, PeerAuthentication) that restrict it, but without an injected proxy you cannot enforce Istio mTLS or rely on many Istio features that assume a proxy is present.
## Default sidecar behavior
By default, an injected Envoy sidecar intercepts both inbound and outbound traffic for a workload. Istio's PeerAuthentication is often left in PERMISSIVE mode unless explicitly configured; permissive mode accepts both mTLS and plaintext traffic. Together, default interception and permissive authentication allow communication between workloads regardless of whether the peer has an Envoy proxy (plaintext clients can talk to permissive mTLS-enabled servers).
For many deployments the defaults are sufficient. Use the Sidecar resource to gain finer-grained control over namespace- or workload-level egress and ingress behavior when needed.
## Restricting egress using a Sidecar resource
You might want to restrict egress from a namespace so workloads can only talk to a small set of permitted namespaces. For example, to limit the `payments` namespace so it can only send outbound traffic to itself, the `app` namespace, and `istio-system`, create a Sidecar resource in `payments`:
```yaml theme={null}
apiVersion: networking.istio.io/v1
kind: Sidecar
metadata:
name: default
namespace: payments
spec:
egress:
- hosts:
- "./*"
- "app/*"
- "istio-system/*"
```
Explanation:
* `./*` — all workloads in the same namespace (`payments/*`).
* `app/*` — every workload in the `app` namespace.
* `istio-system/*` — every workload in the `istio-system` namespace.
With this Sidecar, outbound traffic from workloads in `payments` will be allowed only to:
* workloads in the same `payments` namespace,
* workloads in `app`, and
* workloads in `istio-system`.
Any other egress destinations are blocked by the sidecar configuration.
## PeerAuthentication and mTLS enforcement
Istio does not enforce mTLS unless you create PeerAuthentication resources. Common modes include:
* PERMISSIVE — accepts both plaintext and mTLS.
* STRICT — requires mTLS for all traffic in the scope (namespace or mesh).
To require mTLS for the `app` namespace, and at the same time enforce the `payments` Sidecar shown earlier, combine PeerAuthentication and Sidecar resources (apply this YAML as `peer-sidecar.yaml`):
```yaml theme={null}
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default
namespace: app
spec:
mtls:
mode: STRICT
---
apiVersion: networking.istio.io/v1
kind: Sidecar
metadata:
name: default
namespace: payments
spec:
egress:
- hosts:
- "./*"
- "app/*"
- "istio-system/*"
```
Important considerations:
* When `STRICT` mTLS is set in a namespace, clients connecting to workloads in that namespace must use mTLS. Typically this requires that client workloads have Envoy sidecars injected so the proxy can handle certificate exchange.
* If a client application implements application-level mTLS with proper certificates and keys, it may communicate without an Envoy proxy, but this is an advanced configuration and not common for standard Istio deployments.
**Common Sidecar/PeerAuthentication outcomes**
| Configuration | Effect |
| --------------------------------------------------------- | -------------------------------------------------------------------------------- |
| Default (Sidecar injected, PeerAuthentication PERMISSIVE) | Envoy intercepts traffic; both plaintext and mTLS are accepted. |
| Sidecar injection disabled, PeerAuthentication PERMISSIVE | No Envoy proxy present; plaintext works, mTLS enforcement not applied via Istio. |
| Sidecar injection enabled, PeerAuthentication STRICT | Istio requires mTLS using Envoy-managed certificates for clients with sidecars. |
| Sidecar resource restricting egress | Limits outbound destinations from workloads to the declared `hosts` only. |
## Example: Bookinfo ratings Sidecar
This example shows a more detailed Sidecar with a workload selector, an ingress port that forwards to a Unix domain socket, and egress rules permitting traffic within `bookinfo` and to `istio-system`:
```yaml theme={null}
apiVersion: networking.istio.io/v1
kind: Sidecar
metadata:
name: ratings
namespace: bookinfo
spec:
workloadSelector:
labels:
app: ratings
ingress:
- port:
number: 9080
protocol: HTTP
name: ratings
defaultEndpoint: unix:///var/run/someuds.sock
egress:
- port:
number: 9080
protocol: HTTP
name: egresshttp
hosts:
- "bookinfo/*"
- hosts:
- "istio-system/*"
```
This declares:
* A Sidecar named `ratings` in the `bookinfo` namespace that applies to pods labeled `app=ratings`.
* An ingress listener accepting HTTP on port 9080 and forwarding to a Unix domain socket (`defaultEndpoint`).
* Egress rules allowing HTTP to workloads in `bookinfo/*` and to `istio-system/*`.
Ensure the namespaces involved in mTLS or Sidecar restrictions have Istio
sidecar injection enabled. Without an injected Envoy, policies that rely on
the proxy cannot be enforced.
## Where to learn more
* Istio Sidecar reference and examples: [https://istio.io/latest/docs/reference/config/networking/sidecar/](https://istio.io/latest/docs/reference/config/networking/sidecar/)
* PeerAuthentication documentation: [https://istio.io/latest/docs/reference/config/security/peer\_authentication/](https://istio.io/latest/docs/reference/config/security/peer_authentication/)
* Sidecar injection and setup: [https://istio.io/latest/docs/setup/additional-setup/sidecar-injection/](https://istio.io/latest/docs/setup/additional-setup/sidecar-injection/)
* Bookinfo example (used above): [https://istio.io/latest/docs/examples/bookinfo/](https://istio.io/latest/docs/examples/bookinfo/)
That wraps up this lesson. A demo demonstrates Sidecar and PeerAuthentication behavior in action.