Mastering Istio Security: Complete Guide to Mutual TLS, Authentication, and Authorization

Introduction

Dividing a monolithic application into multiple atomic services improves flexibility, scalability, and reusability, but introduces specific security requirements such as traffic encryption, fine‑grained access control, and audit capabilities.

Istio Security Overview

Istio offers a complete security solution that protects services regardless of where they run. Its security features include strong identity, policy enforcement, transparent TLS encryption, and AAA (authentication, authorization, and audit).

High‑Level Architecture

Istio’s security components consist of a Certificate Authority (CA) for key and certificate management, API server configuration distributed to sidecars (authentication policies, authorization policies, and secure naming information), and sidecar or perimeter proxies that act as Policy Enforcement Points (PEP). The control plane receives configuration from the API server and programs the data‑plane Envoy proxies to enforce policies, with mutual TLS enabled by default (ISTIO_MUTUAL).

Identity

Identity is the foundation of Istio security. During workload‑to‑workload communication, both sides exchange credentials carrying their identities for mutual authentication. The client matches the service’s identity against secure naming information, while the server applies authorization policies based on the client’s identity. Istio uses a service identity (service account) as the primary identifier, supporting platforms such as Kubernetes service accounts, GCP service accounts, AWS IAM roles, and custom accounts.

Certificate Management

Istio uses X.509 certificates issued by its built‑in CA. Each Envoy sidecar runs an Istio agent that works with istiod to automatically rotate certificates. The certificate issuance flow involves istiod providing a gRPC CSR service, the Envoy sidecar generating a private key and CSR, the CA signing the CSR, and the agent delivering the certificate back to Envoy. This process repeats periodically to keep certificates fresh.

Authentication

Istio supports two authentication types:

Peer authentication (mutual TLS) – provides service‑to‑service identity verification without code changes. Modes include PERMISSIVE (accepts both plaintext and TLS), STRICT (TLS only), and DISABLE.

Request authentication – validates JSON Web Tokens (JWT) from end users, supporting providers such as ORY Hydra, Keycloak, Auth0, Firebase Auth, and Google Auth.

Authentication policies are stored in the Istio config store and applied to workloads via

PeerAuthentication

or

RequestAuthentication

resources. Istio can operate in permissive mode to ease migration of non‑sidecar workloads.

Authorization

Istio’s authorization model uses

AuthorizationPolicy

CRDs to enforce access control at mesh, namespace, or workload level. Policies consist of a selector, an action (ALLOW or DENY), and a list of rules that specify sources, destinations, operations, and optional conditions (when). Deny policies take precedence over allow policies. Istio evaluates policies locally in each Envoy proxy, providing high performance and support for HTTP, HTTPS, HTTP/2, and TCP protocols.

Examples include allowing specific principals, restricting paths, and applying port‑level TLS settings. Policies can also use custom conditions based on request headers, source principals, or other attributes.

Mutual TLS Dependencies

Fields such as

source.principals

,

source.namespaces

,

source.principal

,

source.namespace

, and

connection.sni

require mutual TLS to be enabled; otherwise, they are ignored.