Below is a detailed explanation of all Istio features listed in your repo.

Authentication in Istio ensures that every workload identity is verified before communication.

There are two types:

• Secures pod-to-pod communication.
• Uses mutual TLS (mTLS) so both sides prove their identity.
• Configured using PeerAuthentication.
• Protects the mesh from impersonation and eavesdropping.

• Validates end-user identity.
• Typically checks JWT tokens passed via headers.
• Configured using RequestAuthentication.

Why it's important: Ensures that only valid workloads & users can communicate within the mesh.

Authorization determines who is allowed to access what.

Implemented via:

You can restrict access using conditions such as:

• Namespace
• Workload selector
• Request path
• Request method
• Source principal (identity)
• IP blocks

Example use cases:

• Only allow app A to call app B
• Block POST requests
• Allow only authenticated users

Why it's important: Provides zero-trust security inside the cluster.

Circuit breaking prevents cascading failures by:

• Limiting concurrent connections
• Limiting pending requests
• Dropping requests when backend is unhealthy
• Triggering outlier detection to eject bad instances

Configured through DestinationRule → trafficPolicy.

Why it's important: Protects your system when a service becomes slow or unstable.

DestinationRules define policies applied AFTER routing including:

• Load balancing algorithms (round robin, least request)
• Connection pools
• Outlier detection
• Subsets (version grouping, e.g., v1/v2)

They usually pair with VirtualService for traffic splitting.

Why it's important: Controls how traffic is handled by Envoy after the routing decision.

Fault Injection simulates real-world failures:

• Delay → simulate slowness
• Abort → return fake HTTP errors

Used for:

• Chaos engineering
• Validating retry logic
• Testing timeouts and failure handling

Configured inside VirtualService.

Gateways manage traffic entering or leaving the mesh.

For inbound connections from outside the cluster.

For outbound connections to external services.

Gateways sit at the edge and act like L7 load balancers for the mesh.

Why it's important: Allows secure and controlled entry/exit points for traffic.

Mirroring duplicates real production traffic to another service version (shadow traffic):

• Primary request goes to v1
• A mirrored copy goes to v2 (for validation)
• User only sees v1 response

Used for:

• Testing new service releases
• Load testing
• Validating behavior

Configured inside VirtualService.

Retries and timeouts help with reliability:

Envoy automatically retries failed requests (timeouts, 503s).

Abort requests that take too long.

Allows you to:

• Avoid infinite wait
• Prevent retry storms
• Tune performance

Configured in VirtualService.

Covers all tools that ensure workloads are protected:

Includes:

• mTLS (PeerAuthentication)
• JWT validation (RequestAuthentication)
• RBAC (AuthorizationPolicy)
• Sidecar egress restrictions
• Network-level access control

Goal: Zero-trust application networking.

ServiceEntry registers external services so they appear inside the mesh.

Example:

• AWS RDS
• External REST APIs
• Legacy VMs

Allows mesh policies (mTLS, routing, telemetry) to apply.

A sub-category of ServiceEntry specifically for internet hosts like:

• google.com
• api.stripe.com
• example.com

You can:

• Allow or restrict external egress
• Route through egress gateway
• Apply mTLS or TLS origination

Sidecar resources restrict what traffic a pod can send or receive.

You can:

• Limit outbound hosts
• Limit inbound ports
• Improve mesh performance
• Reduce memory footprint

Example: Allow only traffic to httpbin and helloworld.

Why it's important: Minimizes blast radius and increases security.

Broad category covering all L7 routing:

• Header-based routing
• Path-based routing
• Weight-based routing (canary deployments)
• Fault injection
• Mirroring
• Retries / Timeouts

Traffic is controlled primarily with:

• VirtualService
• DestinationRule

Central Istio resource that defines HOW traffic is routed.

Supports:

• Canary deployments
• A/B testing
• Version routing (v1/v2)
• Header/path matching
• Fault injection
• Mirroring
• Redirects & rewrites

VirtualService = brain of Envoy routing.

This is how Istio adds VMs or external machines into the mesh.

• Registers a non-Kubernetes workload as part of Istio
• Assigns workload identity
• Enables mTLS with Kubernetes pods

Used for:

• Hybrid deployments (VM + K8s)
• Migrating legacy systems