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"]