Module 7: Service Mesh Security

Learning Objectives

• Understand service mesh architecture and security capabilities
• Deploy Istio with mTLS enforcement
• Configure identity-aware authorization policies
• Integrate SPIRE as the mesh identity provider

Why This Matters

Service meshes are the most practical way to deploy zero trust at scale. Instead of modifying every application to handle mTLS, the mesh proxy handles it transparently. This module teaches you to deploy and configure the encryption and authorization layer for production Kubernetes.

Lesson Content

A service mesh adds a sidecar proxy (typically Envoy) to every pod. The proxy handles mTLS, load balancing, retries, and observability — transparently, without application code changes. For security, this means automatic encryption and authentication for all service-to-service traffic.

Service Mesh Security Capabilities

• Automatic mTLS: All traffic encrypted and mutually authenticated without application changes
• Identity propagation: SPIFFE IDs flow through the proxy chain for end-to-end verification
• Authorization policies: Fine-grained rules based on service identity, method, path
• Traffic policies: Rate limiting, circuit breaking, fault injection for resilience

Istio Security Model

Istio enforces mTLS via PeerAuthentication resources and authorization via AuthorizationPolicy resources. When combined with SPIRE as the identity provider, you get stronger attestation than Istio default CA provides.

# Enforce strict mTLS on all services in production namespace
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: strict-mtls
  namespace: production
spec:
  mtls:
    mode: STRICT
---
# Only allow orders-api to access the database
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-orders-to-db
  namespace: production
spec:
  selector:
    matchLabels:
      app: database
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/production/sa/orders-api"]
      to:
        - operation:
            methods: ["GET", "POST"]

Real-World Use Cases

• Transparent mTLS for all east-west traffic
• Identity-based authorization in Istio
• Service mesh migration from permissive to strict mTLS
• Envoy SDS integration with SPIRE

Common Mistakes

• Enabling permissive mTLS instead of strict — allows plaintext fallback
• Not testing AuthorizationPolicies before enforcing — blocks legitimate traffic
• Running service mesh without understanding resource overhead (CPU, memory per sidecar)
• Deploying mesh without SPIRE — default Istio CA uses weaker attestation

Production Story

During an Istio migration, a team enabled strict mTLS without checking all services. 12 services that bypassed the sidecar proxy broke immediately. Lesson: migrate from permissive to strict incrementally, one namespace at a time.

Career Relevance

Service mesh expertise combined with security knowledge is a rare and valuable skill set. Organizations deploying Istio at scale need engineers who understand both.

Key Terms

Service Mesh

Infrastructure layer of sidecar proxies handling L7 traffic between services

Envoy

High-performance proxy used as the sidecar in most service meshes

PeerAuthentication

Istio resource controlling mTLS mode (permissive/strict)

AuthorizationPolicy

Istio resource controlling which services can access which endpoints

Hands-On Labs

1. Deploy Istio with Strict mTLS

   Enable automatic encryption for all service traffic.

   35 min - Intermediate

   • Install Istio with default profile
   • Enable sidecar injection
   • Deploy sample application
   • Enforce strict mTLS and verify encryption

   View lab files on GitHub

2. Configure Identity-Based Authorization

   Restrict service access based on SPIFFE identities.

   30 min - Intermediate

   • Create AuthorizationPolicy resources
   • Allow only specific services to access database
   • Test that unauthorized services are rejected (403)
   • View access logs in Envoy

   View lab files on GitHub

Key Takeaways

• Service meshes provide transparent mTLS — no application code changes
• Envoy sidecars handle encryption, authentication, and authorization
• Istio PeerAuthentication enforces mTLS, AuthorizationPolicy enforces access
• SPIRE can replace Istio CA for stronger workload attestation
• Service mesh + SPIFFE = the infrastructure layer of zero trust