Istio Service Mesh: How It Works and How to Deploy It Securely

Istio is the most widely deployed open-source service mesh, and as of mid-2026 it is also the most flexible. You can run it as classic sidecars, run it sidecar-free in ambient mode, or mix both in the same cluster. The version of Istio shipping in May 2026 (1.29.3) is the first release where the ambient option is mature enough to recommend as a default for new deployments. That changes how teams should approach new installs.

This guide walks through Istio’s architecture in both modes, what you get for free on the security side, where the sharp edges are, and how to harden an Istio install before you point real traffic at it. For the broader context on what a service mesh does and why you would deploy one at all, start with What Is a Service Mesh? Architecture, Benefits, and Security Trade-Offs.

Istio’s two data planes

Istio runs a control plane called istiod that handles certificate issuance, configuration distribution, and service discovery. That part is the same in both modes. The difference is in how traffic is intercepted.

Sidecar mode is the original architecture. Each application pod gets an Envoy proxy injected as a sidecar container. The proxy intercepts every connection to and from the application. This is the most mature mode, with years of production hardening behind it. It is also the most resource-hungry. Every pod pays for a full Envoy proxy whether or not it needs Layer 7 features.

Ambient mode reached general availability in Istio 1.24 in November 2024 and has been stable through several releases since. It splits the data plane in two:

• Ztunnel is a per-node proxy written in Rust. It handles Layer 4 work: mutual TLS, identity, basic authorization, and telemetry. There is one ztunnel per node, shared by every pod on that node. It runs as a DaemonSet.
• Waypoint proxies are Envoy instances that run at the namespace level when you need Layer 7 work, like HTTP routing or richer authorization policies. You deploy waypoints only for the namespaces that need them.

Both modes interoperate. A namespace running in ambient mode can talk to a namespace running with sidecars. That makes incremental migration possible, which matters because most real clusters cannot afford a flag day.

For new clusters in 2026, start with ambient unless you have a specific reason not to. The resource savings are large, you avoid pod restarts when adopting the mesh, and the operational story is simpler. For existing sidecar deployments, plan a phased migration rather than a wholesale switch.

What Istio gives you on day one

With a default Istio install on a fresh cluster, you get:

• Mutual TLS between meshed workloads. Istio’s CA issues short-lived SPIFFE identities to each workload, rotates them automatically, and uses them on both sides of every internal connection. By default Istio runs in PERMISSIVE mode, which accepts both plaintext and mTLS so that you can roll the mesh out without breaking unmeshed services. The first hardening task in any new install is to move to STRICT mode for namespaces where you control all the workloads.
• Cryptographic workload identity. Every workload gets a SPIFFE ID that encodes its service account and namespace, such as spiffe://cluster.local/ns/payments/sa/checkout. You write authorization rules against those identities, not IP addresses.
• Telemetry on every request. Latency, status code, source identity, destination identity, and HTTP method, all emitted as metrics and access logs that flow into your observability stack.
• Traffic management primitives. Retries, timeouts, traffic splitting, fault injection, and circuit breakers, configured through VirtualService and DestinationRule resources.

None of that requires code changes in the application. The mesh handles it.

AuthorizationPolicy: the power and the pitfalls

AuthorizationPolicy is Istio’s main security primitive. It lets you write declarative rules about who can call what. A typical rule looks like this:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: payments-allow-checkout
  namespace: payments
spec:
  selector:
    matchLabels:
      app: payments
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/checkout/sa/checkout"]
    to:
    - operation:
        methods: ["POST"]
        paths: ["/charge"]

That rule says: the workload running as the checkout service account in the checkout namespace can POST to /charge on the payments service. Nothing else is allowed. Any other source, method, or path gets a 403 from the proxy before the application code ever sees it.

This is powerful, and it has sharp edges.

The default is allow. If no AuthorizationPolicy targets a workload, every request is allowed. The right pattern is to deploy a namespace-wide default-deny policy first, then add explicit allow rules. Skipping that step means your “default deny” is actually a default allow.

Selectors apply additively across policies. Multiple AuthorizationPolicy resources can apply to the same workload. ALLOW rules union. DENY rules take precedence over ALLOW. The interaction is easy to get wrong. Centralize policy authoring and review policies in pull requests the way you would Kubernetes RBAC.

The serviceAccount field has had a regex bug. In Istio versions 1.25.0 through 1.29.1, the serviceAccounts and notServiceAccounts fields treated the dot character as a regex wildcard. A policy targeting cert-manager.io would also match cert-managerXio. The fix shipped in 1.27.9, 1.28.6, and 1.29.2. If you are running anywhere in that range and you have not patched, do it now. This is the kind of defect that exists in any complex system, which is why a hardened deployment includes a process for tracking and applying upstream security releases.

JWT-based rules look easier than they are. Istio can validate JWTs at the proxy and apply rules against claims. Misconfigured RequestAuthentication and AuthorizationPolicy pairs can produce policies that look strict on paper but allow unauthenticated requests in practice. Test the rejection path, not only the happy path. Confirm that requests without a valid token are denied.

For deeper patterns on fine-grained authorization including OPA integration and attribute-based control, see our Fine-Grained Authorization: A Technical Guide for Microservices.

Hardening checklist for a new Istio install

Before you point any production traffic at an Istio install, run through this list:

1. Move to STRICT mTLS. Apply a PeerAuthentication resource at the mesh, namespace, or workload level that requires mTLS. PERMISSIVE mode exists for migration, not for a steady state.
2. Default-deny authorization. Apply a namespace-wide AuthorizationPolicy with no rules and action: DENY, then layer explicit ALLOW rules on top.
3. Restrict istiod RBAC. Istiod runs with broad Kubernetes RBAC by default to enable its features. Audit what it needs in your environment and tighten where possible. Treat istiod as critical infrastructure.
4. Patch the control plane and data plane on the same cadence. Istio releases a new minor version roughly every three months and patches monthly. Your patching window for both istiod and the proxies should be measured in days, not quarters.
5. Enable access logs and feed them to your SIEM. This is your audit trail. Treat the access log stream as a tier-one observability source.
6. Lock down istiod’s debug endpoints. Istiod exposes a debug port that can leak configuration helpful to an attacker. Restrict access with a NetworkPolicy and disable the endpoint in production where you can.
7. Verify certificate rotation works. Force a workload restart and confirm that new certificates are issued cleanly. A mesh whose certificate rotation has silently broken will fail catastrophically later.
8. Test failure modes. Kill an istiod replica during traffic. Verify that meshed workloads continue serving traffic on their existing certificates. Run that game day before you find out under real conditions.
9. Pin proxy and CNI plugin versions. Use admission control to prevent ad-hoc upgrades of the data plane.

That is the minimum. A fully hardened Istio install also integrates with external CA infrastructure, runs multiple control-plane replicas across availability zones, and uses ambient mode’s L4 policies as a fallback layer even when waypoint proxies are deployed.

For the deeper mechanics of mTLS, certificate provisioning, and access control inside Istio, read our Service Mesh Security: A Deep Dive into mTLS and Access Control for Microservices.

When Istio fits and when it does not

Istio fits well when:

• You run more than 20 services and need rich Layer 7 policy.
• Your services are multi-language and you cannot enforce mTLS through a shared library.
• Your team has the operational capacity to run a non-trivial distributed control plane.
• You need compliance evidence that internal traffic is encrypted and authorized.

Istio is the wrong choice when:

• Your team is small and you are running fewer than ten services. The operational cost will not be repaid.
• You are already running Cilium as your CNI and invested in eBPF. Cilium Service Mesh may be a better fit.
• You need a mesh primarily for Layer 4 mTLS and identity, with minimal Layer 7 policy. Linkerd or Cilium will be lighter weight.

There is no prize for running the most-featured mesh in the smallest cluster. Pick the tool that matches your problem. The broader trade-off framework lives in our service mesh architecture pillar.

Bottom line

Istio in 2026 is two products that share a control plane: the mature sidecar architecture and the lighter-weight ambient architecture. Both deliver the same security primitives. The differences are operational and architectural. For new installs we recommend ambient. For existing sidecar fleets we recommend migration on a deliberate timeline rather than a flag day.

The security value is real and the operational cost is real. Plan for both, and harden the install before production traffic hits it. The default Istio configuration is built for ease of adoption, not for the threat model your security team is defending against. Closing that gap is your job.

If you want a second opinion on an Istio deployment, or help planning a migration from sidecar to ambient, schedule a conversation with our engineers. For a broader baseline on your security posture, start with the Free Human Attack Surface Score assessment.

Director of Information Security

Chris Armour

The Breaker & Builder.

Operating on the philosophy that 'you can't build a secure system if you don't know how to break it,' Chris leads our engineering division. A top 1% National Cyber League competitor, he hardens our digital infrastructure against the very exploits he has mastered.

View Author Page →