Service Mesh and Privacy: How Istio and Envoy Enable Zero-Trust Networking

In a traditional network, services trust each other because they share a network perimeter. A request from 10.0.3.47 is trusted because 10.0.3.47 is inside the firewall. This trust model — implicit, perimeter-based, binary — collapses the moment any single service is compromised. An attacker who breaches one service inherits the network trust of every service on the same network segment.

The 2020 SolarWinds breach demonstrated this at national scale. Compromised software inside the trusted perimeter moved laterally across government and enterprise networks for nine months without triggering perimeter-based security controls. The perimeter was intact. The interior was compromised. The trust model failed because it assumed that internal equals safe.

Service mesh architectures replace this implicit trust with cryptographic identity, mutual authentication, and fine-grained authorization at every service-to-service connection. In a service mesh, no service trusts any other service by default. Every connection is authenticated. Every request is authorized against a policy. Every payload is encrypted in transit. This is zero-trust networking implemented at the infrastructure layer — not as a philosophy, but as packet-level enforcement.

What a Service Mesh Is (and Is Not)

A service mesh is a dedicated infrastructure layer that handles service-to-service communication. It typically consists of two components:

Data plane: A network of lightweight proxies (sidecars) deployed alongside each service instance. Every inbound and outbound network call passes through the sidecar proxy. Envoy (used by Istio) and linkerd2-proxy (used by Linkerd) are the dominant data plane implementations.

Control plane: A centralized management component that configures the sidecar proxies — distributing certificates, pushing authorization policies, and collecting telemetry. Istiod (Istio’s control plane) and the Linkerd control plane are the primary implementations.

A service mesh is not a firewall. It is not a WAF. It is not an API gateway. It operates at a different layer — mediating communication between internal services rather than filtering external traffic. A request that has passed the API gateway and entered the cluster still must authenticate and be authorized at every internal service boundary.

The CNCF’s 2025 Service Mesh Survey found that 47% of organizations running Kubernetes in production had adopted a service mesh, up from 28% in 2023. Among organizations with more than 100 microservices, adoption was 71%. The growth is driven by operational needs (traffic management, observability) but the privacy benefits are increasingly cited as a primary driver.

Mutual TLS: The Foundation

Mutual TLS (mTLS) is the cryptographic foundation of service mesh privacy. In standard TLS, the client verifies the server’s identity but the server accepts any client. In mTLS, both parties present certificates, and both verify the other’s identity.

How Istio Implements mTLS

Istio’s mTLS implementation is transparent to application code. The process:

1. Certificate issuance: Istiod acts as a Certificate Authority (CA), issuing SPIFFE-compliant X.509 certificates to each service’s sidecar proxy. The certificate encodes the service’s identity (namespace, service account) in the SPIFFE ID: spiffe://cluster.local/ns/production/sa/user-service.

2. Certificate rotation: Certificates are short-lived (default 24 hours) and automatically rotated. Short certificate lifetimes reduce the window of exposure if a certificate is compromised.

3. Transparent encryption: When Service A calls Service B, the Envoy sidecar on Service A initiates a TLS connection to the Envoy sidecar on Service B. Both present their certificates. Both verify the other’s certificate against the mesh CA. The application code sends and receives plaintext; the sidecar handles all encryption.

4. STRICT mode: Istio can be configured to require mTLS for all mesh traffic (PeerAuthentication: STRICT). In strict mode, any connection without a valid mesh certificate is rejected. No exceptions. No fallback to plaintext.

The privacy property: in an Istio mesh with strict mTLS, every byte of service-to-service communication is encrypted with TLS 1.3, authenticated with SPIFFE certificates, and visible only to the two communicating services. A compromised service cannot eavesdrop on traffic between other services. A network-level attacker (or a compromised switch, router, or cloud networking layer) sees only encrypted traffic with no plaintext payloads.

The Encryption Gap Without a Mesh

Without a service mesh, inter-service encryption depends on application developers. Each service must implement TLS, manage certificates, handle rotation, and verify peer identity. In practice, many internal services communicate in plaintext because implementing mutual TLS is operationally complex and “internal traffic doesn’t need encryption.”

A 2025 audit by the Kubernetes security firm ControlPlane found that in organizations without a service mesh, 43% of inter-service traffic within Kubernetes clusters was unencrypted. In organizations with a service mesh in strict mTLS mode, unencrypted inter-service traffic was 0%.

That 43% represents a significant privacy exposure. Network-adjacent attacks, compromised nodes, and misconfigured network policies can all expose plaintext internal traffic. Kubernetes pod-to-pod traffic traverses a virtual network that — depending on the CNI plugin — may not encrypt at the network layer. The service mesh fills this gap universally and transparently.

Fine-Grained Authorization

mTLS provides authentication (verifying identity) and encryption (protecting data in transit). Authorization — deciding what an authenticated service is allowed to do — is the second privacy pillar of the service mesh.

Istio Authorization Policies

Istio authorization policies operate at Layer 7 (HTTP) and can make access decisions based on:

• Source identity: Which service is making the request (derived from the mTLS certificate)
• Destination: Which service and endpoint is being accessed
• HTTP method: GET, POST, PUT, DELETE
• Request headers: Custom headers, JWT claims, or other request metadata
• Source namespace: The Kubernetes namespace of the calling service

A privacy-enforcing authorization policy might look like:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: pii-access-control
  namespace: user-data
spec:
  selector:
    matchLabels:
      app: user-profile-service
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/production/sa/account-service"]
    to:
    - operation:
        methods: ["GET"]
        paths: ["/api/v1/profiles/*"]
  - from:
    - source:
        principals: ["cluster.local/ns/production/sa/admin-service"]
    to:
    - operation:
        methods: ["GET", "PUT"]
        paths: ["/api/v1/profiles/*"]

This policy restricts the user profile service — which handles PII — to accept requests only from the account service (read-only) and the admin service (read-write). All other services in the mesh are denied. The policy is enforced at the Envoy proxy level, before the request reaches the application code.

The privacy benefit is defense in depth. Even if the application’s own authorization logic has a bug, the mesh-level policy prevents unauthorized services from reaching the endpoint. The zero-trust principle is enforced at two layers: the mesh and the application.

Comparing Istio, Linkerd, and Cilium

The three leading service mesh implementations differ in their privacy-relevant capabilities:

For privacy-focused architectures, the key differentiator is authorization granularity. Istio’s L7 policies allow path-level access control, meaning you can restrict which services can access /api/pii/ endpoints specifically. Cilium’s eBPF-based approach has lower performance overhead but historically offered coarser-grained authorization (though recent versions have added L7 filtering via Envoy integration).

Linkerd’s advantage is simplicity and a Rust-based data plane with a smaller memory and security footprint. The linkerd2-proxy is approximately 12MB of memory versus Envoy’s 60MB, and Rust’s memory safety guarantees reduce the risk of proxy-level vulnerabilities.

Observability: The Privacy Tension

Service meshes generate observability data by design. The sidecar proxy sees every request and can report:

• Request count, latency, and error rate (the “golden signals”)
• Full request and response headers
• Request and response bodies (with appropriate configuration)
• Source and destination identity for every connection
• TLS handshake details and certificate metadata

This observability is operationally valuable and privacy-concerning. The same data that helps debug a latency issue can reveal access patterns, user behavior, and sensitive request content.

Configuring Privacy-Respecting Observability

Istio’s telemetry can be configured to balance observability with privacy:

Disable access logging for sensitive services: Istio access logs capture request details including paths and headers. For services handling PII, access logging should be disabled or limited to metadata-only:

apiVersion: telemetry.istio.io/v1
kind: Telemetry
metadata:
  name: sensitive-service-telemetry
  namespace: user-data
spec:
  accessLogging:
  - disabled: true

Redact headers in telemetry: Custom headers that might contain tokens, session identifiers, or user information should be excluded from telemetry collection. Envoy supports header redaction in access log formats.

Aggregate metrics, not individual requests: Rather than logging individual request details, aggregate metrics (request count, p99 latency, error rate) by service pair and time window. Aggregated metrics provide operational visibility without per-request privacy exposure.

The observability-privacy tension is inherent in service mesh architecture. The mesh sees everything by design. The configuration determines how much of what it sees is recorded, stored, and made accessible.

Service Mesh for Multi-Cluster and Hybrid Cloud

Service mesh privacy properties become particularly valuable when the mesh spans multiple clusters or hybrid cloud environments.

Multi-Cluster mTLS

Istio’s multi-cluster configuration extends mTLS across cluster boundaries. Services in Cluster A can call services in Cluster B with the same mTLS guarantees as intra-cluster communication. The cross-cluster traffic is encrypted, authenticated, and authorized by the same policies.

This is significant for hybrid cloud architectures where some clusters run on-premises and others run in public cloud. Without a service mesh, the inter-cluster link — typically a VPN or direct connect — provides transport encryption but not service-level authentication. Any service on either side of the VPN can communicate with any service on the other side. The service mesh adds the identity-based access control layer that the VPN lacks.

Federation and Trust Domain Boundaries

Large organizations may operate multiple independent service meshes with different trust domains. Istio’s trust domain federation allows meshes to establish mutual trust, enabling cross-mesh communication while maintaining independent certificate authorities.

The privacy implication: federation allows organizations to extend zero-trust networking across organizational boundaries (such as between business units, or between a company and its partners) without sharing a single certificate authority. Each mesh maintains its own identity system, issues its own certificates, and controls its own authorization policies. Cross-mesh trust is explicit and scoped, not implicit and universal.

Performance and Privacy: The Sidecar Tax

The sidecar proxy model introduces latency. Every service-to-service call traverses two sidecars (source and destination), adding mTLS handshake time, proxy processing, and context switching overhead.

Benchmarks from the Istio performance team (published January 2026) show:

• Latency: 2.5ms median additional latency per hop for mTLS-encrypted traffic (Envoy sidecar), 1.1ms for Linkerd’s Rust proxy, <0.5ms for Cilium’s eBPF data plane
• CPU overhead: 0.5-1.5 vCPU per 10,000 requests/second for Envoy, 0.2-0.5 vCPU for linkerd2-proxy
• Memory overhead: 50-100MB per Envoy sidecar, 10-20MB per linkerd2-proxy

For privacy-sensitive architectures, this overhead is the cost of encryption and authentication at every service boundary. The question is not whether the overhead is acceptable — it is whether the alternative (unencrypted, unauthenticated inter-service traffic) is acceptable.

Cilium’s sidecar-less architecture (using eBPF programs in the kernel) reduces this overhead substantially, but eBPF programs operate at the kernel level, which introduces a different trust consideration: a compromised eBPF program has kernel-level access. The sidecar model’s user-space proxies have a more limited blast radius if compromised.

Emerging Patterns: Ambient Mesh and Sidecar-less

Istio’s ambient mesh mode, generally available since early 2026, replaces per-pod sidecars with node-level proxies (ztunnel) for L4 encryption and optional per-service L7 proxies (waypoint proxies) for authorization:

• ztunnel: A lightweight, Rust-based L4 proxy running as a DaemonSet on each node. It handles mTLS for all mesh traffic without requiring a sidecar in each pod. Memory overhead drops from 50-100MB per pod to a single 20-40MB process per node.
• Waypoint proxies: Optional L7 proxies deployed per-service or per-namespace for services requiring fine-grained authorization. Only services that need L7 policies get L7 proxies.

The privacy properties of ambient mesh are equivalent to sidecar-based mesh for L4 (encryption and identity). L7 authorization requires waypoint proxies. The operational benefit is reduced resource consumption and simpler deployment, which lowers the barrier to mesh adoption.

For organizations that have deferred service mesh adoption due to sidecar overhead — and consequently operate without inter-service encryption — ambient mesh removes the primary objection.

The Stealth Cloud Perspective

Service mesh architecture solves a real and important problem: encrypting and authenticating service-to-service communication. For organizations operating microservice architectures, a service mesh is the most practical path to zero-trust networking. The mTLS encryption, identity-based authorization, and policy enforcement capabilities are mature, well-tested, and operationally viable.

But service mesh privacy has a scope limitation. It protects data in transit between services. It does not protect data at rest within services. It does not prevent a service from logging, storing, or leaking the plaintext data it legitimately receives through an authorized, encrypted connection.

Stealth Cloud addresses this limitation by ensuring that services never receive plaintext sensitive data in the first place. Client-side encryption and PII stripping occur before data enters the service mesh. The mesh then transports ciphertext between services that cannot decrypt it. Authorization policies restrict which services can handle which ciphertext — but even a breach of authorization results in exposure of encrypted data, not cleartext.

This is the layered defense model: the service mesh provides zero-trust networking (authentication, authorization, encryption in transit), while client-side cryptography provides zero-knowledge computing (the services never possess the cleartext). Either layer alone is insufficient. Together, they create infrastructure where privacy is enforced at the network layer and the data layer simultaneously.

The service mesh is the skeleton. The encryption is the armor. Both are necessary. Neither is sufficient alone.