Mastering Istio Security: A Deep Dive into Authentication, Authorization, and mTLS

Dividing a monolithic application into atomic services improves flexibility, scalability, and reuse, but microservices have special security requirements.

Defend against man‑in‑the‑middle attacks with traffic encryption.

Provide fine‑grained access control using TLS and policies.

Audit who does what and when with logging tools.

Istio offers a complete security solution that works regardless of where services run, reducing internal and external threats to data, endpoints, communication, and platforms.

Istio Security Features

Istio provides strong identity, policy, transparent TLS encryption, and AAA (authentication, authorization, audit) to protect services and data. Its security goals are:

Default security without code or infrastructure changes.

Deep protection that integrates with existing security systems.

Zero‑trust networking on untrusted networks.

Refer to the mutual TLS migration guide for details on enabling Istio security on already‑deployed services.

High‑Level Architecture

Istio security involves several components:

Certificate Authority (CA) for key and certificate management.

API server configuration distributed to sidecars, including authentication and authorization policies and secure naming information.

Sidecar and perimeter proxies acting as policy enforcement points (PEP) to secure client‑server communication.

Envoy extensions for telemetry and audit.

Istio Identity

Identity is the foundation of all security mechanisms. During workload‑to‑workload communication, both sides exchange credentials containing their identities for mutual authentication. The client matches the service’s identity against secure naming information to verify the workload, while the server uses authorization policies to decide what the client may access.

Istio’s identity model uses a service identity (first‑level service identifier) to determine the request source. It can represent a user, a single workload, or a group of workloads. On platforms without service identifiers, Istio can fall back to other identifiers such as service names.

Supported service identifiers include:

Kubernetes service account

GKE/GCE GCP service account

AWS IAM user/role

On‑premises: user account, custom service account, service name, Istio service account, or GCP service account.

Identity and Certificate Management

Istio uses X.509 certificates for strong identity. An Istio agent runs alongside each Envoy proxy and works with istiod to automatically rotate certificates. The certificate provisioning flow is:

istiod provides a gRPC service for handling CSR (Certificate Signing Requests).

Envoy sends certificate and key requests via the Envoy SDS API.

The Istio agent creates a private key and CSR, then sends the CSR to istiod.

The CA validates the CSR and issues a certificate.

The agent delivers the certificate and key to Envoy via the SDS API.

This process repeats periodically to rotate keys and certificates.

Authentication

Istio provides two authentication types:

Peer authentication (service‑to‑service) using mutual TLS, requiring no code changes. It provides strong identities, cross‑cluster interoperability, and automatic key management.

Request authentication (end‑user) validates JSON Web Tokens (JWT) and can integrate with ORY Hydra, Keycloak, Auth0, Firebase Auth, Google Auth, etc.

Authentication policies are stored in the Istio config store and pushed to each proxy. Istio also supports a permissive mode that allows both plaintext and mTLS traffic during migration.

Mutual TLS Authentication

When a workload uses mutual TLS to call another workload, the flow is:

Outbound traffic is redirected to the client’s sidecar Envoy.

The client Envoy and server Envoy perform a mutual TLS handshake, including secure naming verification.

After the handshake, the client Envoy forwards traffic to the server Envoy.

The server Envoy forwards the traffic to the destination service.

Permissive Mode

Permissive mode allows a workload to accept both plaintext and TLS traffic, easing migration of non‑sidecar workloads. After sidecars are injected, the mode can be switched to STRICT.

Security Naming

Service credentials embed identity, while the service name is discovered via DNS or service discovery. Secure naming maps an identity (e.g., A) to a service name ( B) and enforces that only the authorized identity can run the service. The control plane watches the API server to generate and distribute these mappings.

Secure naming prevents HTTPS hijacking and mitigates TCP hijacking, though it cannot stop DNS spoofing.

Authentication Architecture

Authentication policies are defined in YAML files and stored in the Istio config store. The Istio controller watches the store and pushes updates to workloads. Policies can be scoped to the mesh, namespace, or specific workloads using the selector field.

When policies change, Istio updates workloads asynchronously. To avoid disruption, Istio recommends transitioning from DISABLE to STRICT via PERMISSIVE, and adding new JWT rules before removing old ones.

Authorization

Istio’s authorization provides access control at mesh, namespace, and workload levels via the AuthorizationPolicy CRD. Policies support ALLOW and DENY actions, flexible semantics, high performance (enforced by Envoy), and compatibility with RPC, HTTP, HTTPS, HTTP2, and plain TCP.

Authorization Architecture

Each Envoy runs an authorization engine that evaluates the current policy set against incoming requests, returning ALLOW or DENY. Policies are defined in YAML files.

Implicit Enable

Authorization is automatically enabled when a policy is applied to a workload. Workloads without a policy are allowed by default.

Authorization Policy Structure

An AuthorizationPolicy contains a selector (target), an action (ALLOW or DENY), and a list of rules. Each rule can specify from (source), to (operation), and when (conditions).

Policy Targets

Policies can be scoped using metadata.namespace and an optional selector. An empty selector applies to all workloads in the namespace; a non‑empty selector limits the policy to matching labels.

Value Matching

Fields support exact, prefix ("*" suffix), suffix ("*" prefix), and existence ("*") matching. Some fields (e.g., when.key, ipBlocks, ports) only allow exact matches.

Exclusion Matching

Negative conditions such as notValue, notIpBlocks, and notPorts can be used to exclude specific paths, IP ranges, or ports.

Allow‑All and Deny‑All Policies

Example allow-all policy permits all traffic in a namespace, while a deny-all policy blocks everything in a namespace.

Custom Conditions

The when clause can match arbitrary request attributes, such as request.headers[version] equal to "v1" or "v2".

Authenticated vs. Unauthenticated Identities

Leaving the source empty allows both authenticated and unauthenticated access. Setting principals: ["*"] restricts access to any authenticated principal.

TCP Authorization

Istio can authorize plain TCP services (e.g., MongoDB) using the same AuthorizationPolicy syntax, but HTTP‑only fields are ignored for TCP workloads.

mTLS Dependencies

Fields such as source.principals, source.namespaces, custom conditions on source.principal, source.namespace, and connection.sni require mutual TLS to be enabled. If none of these fields are used, mTLS is not required.

For a complete reference, see the original article: https://www.cnblogs.com/charlieroro/p/13588569.html