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:
ComponentRoleExample Configuration
Sidecar ProxyIntercepts and secures pod-to-pod trafficsidecar.istio.io/inject: "true"
Ingress GatewayTerminates external traffic, applies edge policiesapiVersion: networking.istio.io/v1beta1 ingress specs
Egress GatewayControls and monitors external egress, policy checksapiVersion: networking.istio.io/v1beta1 egress specs

​
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

# Example: Enforce strict mTLS namespace-wide
kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: your-namespace
spec:
  mtls:
    mode: STRICT
EOF
  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