Sidecar Proxy for TLS Handshakes

• Istio uses a sidecar proxy (Envoy) injected into each pod to handle TLS handshakes.

Automatic Cert rotation

Certificates are issued, rotated, and renewed automatically via Istio’s control plane (istiod), reducing operational overhead compared to manually setting up cert-manager or similar in plain Kubernetes.

• As we have seen in Kubernetes with Helm example, we would use cert-manager with an ingress controller (e.g., NGINX) to secure external traffic, but internal pod-to-pod mTLS requires manual certificate distribution or custom app logic. Istio handles this transparently.

Fine-Grained Security Policies

• Istio lets you define mTLS (Mutual TLS, between an application and its client, which could be another pod or external application) policies at a granular level (e.g., per namespace, per service, or even per workload) using its PeerAuthentication and AuthorizationPolicy resources.
• You can enforce mTLS globally or selectively (e.g., strict mode for sensitive services, permissive for others). In plain Kubernetes, you’d rely on network policies and ingress annotations, which are less flexible for internal traffic.
• mTLS everywhere
  • North–South (external ↔ cluster): Client ↔ Ingress/Gateway uses TLS; with mTLS, the client also presents a cert (you did this with NGINX).
  • East–West (service ↔ service inside cluster): Every hop between workloads is encrypted and mutually authenticated (both sides prove identity).
• Istio has Zero Trust by Default
• Istio assumes no trust between services, ensuring all communication is encrypted and authenticated. This aligns with zero-trust security models, critical for sensitive apps or multi-tenant clusters

Istio can do AuthZ and AuthN

• At the mesh (Istio) level — good for coarse-grained gates and defense-in-depth.
  • Authenticate end-users with JWT/OIDC (RequestAuthentication), and
  • Authorize using claims (AuthorizationPolicy), e.g. “role=writer can call POST /v1/orders”.
  • Pros: uniform, language-agnostic, blocks bad traffic before it reaches code.
  • Cons: not ideal for deep, business-specific rules (e.g., “User A can transfer up to X based on account state”).
• At the application level — for fine-grained business logic (object-/row-level checks, domain rules).
  • The app still receives verified identity/claims from the mesh (headers) and enforces detailed policy.

Observability

• Built in Tracing: Beyond mTLS, Istio provides built-in metrics, tracing, and logs (via tools like Prometheus, Grafana, and Jaeger) to monitor encrypted traffic. This is great for debugging mTLS issues or performance bottlenecks.

Advanced traffic routing and management

(allows for canary deployments (route 10% traffic to new version of API), A/B testing), which integrates well with mTLS for secure rollouts. Plain Kubernetes ingress offers basic routing but lacks these advanced features without additional tools.Example