mTLS and Mesh Security — Vocabulary

mTLS = both parties authenticate — the server verifies the client's certificate, and the client verifies the server's certificate. This enables zero-trust service-to-service authentication.

In a typical HTTPS connection (regular TLS), only the server presents a certificate. The browser verifies the server is legitimate, but the server doesn't verify who the browser is (authentication is done via cookies/tokens at the application layer). In Istio mTLS, the payment-service doesn't just verify that it's talking to the order-service's IP address — it verifies the order-service's SPIFFE certificate. If a rogue container with the same IP somehow intercepts traffic, it won't have the valid SPIFFE certificate and the mTLS handshake will fail.

Key vocabulary:
• mutual TLS (mTLS) — both parties present and verify X.509 certificates
• workload identity — the SPIFFE certificate Istio issues to each service's Envoy sidecar
• SPIFFE — Secure Production Identity Framework for Everyone; standard for workload identity in cloud-native systems

PERMISSIVE mode is the migration-friendly setting — it accepts both mTLS and plain-text, allowing teams to gradually onboard services before switching to STRICT.

A common Istio rollout pattern: (1) set PeerAuthentication to PERMISSIVE cluster-wide while enabling sidecar injection namespace by namespace — services with sidecars automatically use mTLS with each other, services without sidecars still work with plain-text; (2) once all namespaces have sidecars and mTLS is confirmed working, switch the cluster-wide PeerAuthentication to STRICT. After that, any plain-text traffic (e.g., from a service outside the mesh, or a misconfigured pod without injection) will be rejected at the Envoy sidecar.

Key vocabulary:
• STRICT mTLS — rejects plain-text; all traffic must use mTLS certificates
• PERMISSIVE mTLS — accepts both mTLS and plain-text; used during mesh migration
• PeerAuthentication — Istio resource setting mTLS mode per namespace or workload

SPIFFE IDs tie service identity to Kubernetes service accounts — the AuthorizationPolicy allows or denies based on cryptographic proof of identity, not IP addresses which can be spoofed.

Istio's built-in CA (Citadel, now part of istiod) issues X.509 certificates to each sidecar. The certificate's Subject Alternative Name (SAN) contains the SPIFFE ID: spiffe://<trust-domain>/ns/<namespace>/sa/<service-account>. When service A connects to service B with mTLS, service B's Envoy extracts the SPIFFE ID from service A's certificate. The AuthorizationPolicy can then match on principal (SPIFFE ID pattern) — for example, only allow requests from spiffe://cluster.local/ns/orders/sa/order-service to the payment endpoint.

Key vocabulary:
• SPIFFE ID — spiffe://<trust-domain>/ns/<namespace>/sa/<sa-name>; workload's cryptographic identity
• principal — in Istio AuthorizationPolicy, the identity of the source service (its SPIFFE ID)
• AuthorizationPolicy source — restricts which principals or namespaces can initiate requests

mTLS provides both authentication AND encryption in a single mechanism — it is TLS with client certificate authentication on top.

TLS itself encrypts data using symmetric keys negotiated during the handshake. mTLS adds mutual authentication to that standard TLS process. So Istio STRICT mTLS: (1) both sidecars exchange and verify certificates (authentication), (2) they negotiate a symmetric session key, (3) all traffic between them is encrypted (encryption). This addresses both the "who are you?" and "is the data private in transit?" questions simultaneously. For compliance requirements like "all data must be encrypted in transit", Istio STRICT mTLS satisfies this for all inter-service communication — with zero application code changes.

Key vocabulary:
• encryption in transit — all bytes on the wire between Envoy sidecars are encrypted via TLS session keys
• authentication — mTLS certificates prove workload identity at connection establishment
• STRICT mTLS — enforces both encryption and mutual authentication for all intra-mesh traffic

AuthorizationPolicy is Istio's L7 access control — it can enforce fine-grained allow/deny rules based on service identity, namespace, HTTP method, and URL path.

Istio uses a default-deny posture when any AuthorizationPolicy exists on a workload: if a policy exists and a request doesn't match any ALLOW rule, it is denied. The policy for this case: spec.selector (matching orders service pods), rules[0].from.source.principals (SPIFFE ID of reporting service), rules[0].to.operation.methods (GET), rules[0].to.operation.paths (/orders/*). Note that NetworkPolicy operates at L3/L4 (IP/port) only — it can't distinguish GET from POST or restrict specific URL paths. AuthorizationPolicy operates at L7 via Envoy.

Key vocabulary:
• AuthorizationPolicy — Istio L7 access control; allow/deny based on identity, method, path
• default deny — when any ALLOW policy exists, traffic not matching it is implicitly denied
• source.principals — SPIFFE IDs of services allowed to initiate requests