Skip to main content
In this article, we explore how Istio’s service mesh delivers end-to-end security for microservices. You’ll learn how Istio issues certificates, enforces mutual TLS (mTLS), and applies authentication and authorization policies across your data plane.
The following diagram illustrates Istio’s security architecture. It shows secure service-to-service communication via Envoy sidecars, how ingress and egress gateways handle external traffic, and how the istiod control plane manages certificates and policies.
The image illustrates the Istio Security Architecture, showing the interaction between services, proxies, and the control plane with secure communication protocols like mTLS. It highlights components such as Ingress, Egress, and the istiod control plane managing certificates and policies.

​
1. istiod Control Plane as Certificate Authority

At the heart of Istio security, the istiod component serves as a built-in certificate authority (CA). It:
  • Issues, rotates, and revokes workload certificates and private keys
  • Manages SPIFFE-based identities for workloads
  • Provides a configuration API server for distributing security policies

​
How Certificate Issuance Works

  1. When a new workload starts, its Envoy sidecar contacts the local Istio agent.
  2. The agent requests a signed certificate and private key from istiod.
  3. Istiod signs the CSR (Certificate Signing Request) and returns credentials.
  4. The proxy establishes mTLS connections to other services using these certs.

​
2. Authentication, Authorization, and Secure Naming

Istio’s configuration API server (part of istiod) pushes the following policies to each Envoy proxy:
  • Authentication Policies: Define which workloads require mTLS or JWT verification.
  • Authorization Policies: Control access based on attributes like source.principal or request.headers.
  • Secure Naming: Ensures that only services with valid SPIFFE identities can communicate.
By enforcing policies at each hop, Istio builds a defense-in-depth model rather than relying on perimeter security alone.

​
3. Data Plane Proxies: Sidecars, Ingress, and Egress Gateways

All traffic—both internal and external—flows through Envoy proxies:

​
Traffic Flow

  • Internal: Service A → its Envoy sidecar (mTLS) → Service B’s sidecar → Service B
  • Ingress: External client → Ingress Gateway → Destination sidecar
  • Egress: Service sidecar → Egress Gateway → External service

​
4. Mutual TLS Handshake

  1. Sidecar A presents its certificate to Sidecar B.
  2. Sidecar B verifies the certificate against Istio’s root CA.
  3. Both proxies agree on encryption keys.
  4. Secure channel established—data is encrypted, authenticated, and authorized.

​
References

Watch Video

Practice Lab