Use when implementing service-to-service security, mTLS, or service mesh patterns. Covers mutual TLS, Istio, Linkerd, certificate management, and service mesh security configurations.
Comprehensive guide to securing service-to-service communication with mutual TLS and service mesh patterns.
Standard TLS (one-way):
Client ──────────────────► Server
Client verifies
server identity
Mutual TLS (two-way):
Client ◄────────────────► Server
Both verify
each other
Standard TLS:
- Server presents certificate
- Client validates server
- Client remains anonymous to server
Mutual TLS:
- Server presents certificate
- Client validates server
- Client presents certificate
- Server validates client
- Both identities verified
mTLS Handshake Flow:
1. Client Hello
└── Client → Server: "Hello, I support these ciphers"
2. Server Hello + Certificate
└── Server → Client: "Let's use this cipher"
└── Server → Client: "Here's my certificate"
└── Server → Client: "Please provide your certificate"
3. Client Certificate
└── Client → Server: "Here's my certificate"
4. Certificate Verification
└── Both sides verify:
- Certificate chain valid
- Not expired
- Not revoked
- Identity matches expected
5. Key Exchange
└── Derive shared session key
6. Encrypted Communication
└── All traffic encrypted with session key
Service Certificate Fields:
Subject:
CN = my-service
O = my-organization
Subject Alternative Names (SANs):
- DNS: my-service.default.svc.cluster.local
- DNS: my-service.default
- DNS: my-service
- URI: spiffe://cluster.local/ns/default/sa/my-service
Issuer: (CA that signed the certificate)
CN = cluster-ca
Validity:
Not Before: 2025-01-01
Not After: 2025-01-08 (short-lived, auto-rotated)
Key Usage:
- Digital Signature
- Key Encipherment
Extended Key Usage:
- TLS Web Server Authentication
- TLS Web Client Authentication
Service Mesh Architecture:
┌─────────────────────────────────────────────────────┐
│ Control Plane │
│ ┌────────────┐ ┌────────────┐ ┌────────────┐ │
│ │ Pilot │ │ Citadel │ │ Galley │ │
│ │ (Config) │ │ (CA) │ │ (Validation)│ │
│ └─────┬──────┘ └─────┬──────┘ └─────┬──────┘ │
└────────┼───────────────┼───────────────┼───────────┘
│ │ │
└───────────────┼───────────────┘
│
┌───────────────▼───────────────┐
│ Data Plane │
┌────────┼────────────────────────────────┼────────┐
│ │ │ │
│ ┌─────▼─────┐ ┌──────▼─────┐ │
│ │ Sidecar │◄─────mTLS───────►│ Sidecar │ │
│ │ (Envoy) │ │ (Envoy) │ │
│ └─────┬─────┘ └─────┬──────┘ │
│ │ │ │
│ ┌─────▼─────┐ ┌─────▼─────┐ │
│ │ Service A │ │ Service B │ │
│ └───────────┘ └───────────┘ │
└──────────────────────────────────────────────────┘
Control Plane Functions:
- Certificate authority (issue/rotate certs)
- Configuration distribution
- Policy management
- Service discovery
Data Plane Functions:
- mTLS termination
- Traffic encryption
- Policy enforcement
- Telemetry collection
Sidecar Injection:
Without Sidecar:
┌───────────────────┐
│ Pod │
│ ┌─────────────┐ │
│ │ App │──────► Network
│ └─────────────┘ │
└───────────────────┘
With Sidecar:
┌────────────────────────────────────┐
│ Pod │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ App │ │ Sidecar │ │
│ │ │──►│ (Envoy) │──────► mTLS ──►
│ │ localhost │ │ handles │ │
│ │ :8080 │ │ security │ │
│ └─────────────┘ └─────────────┘ │
└────────────────────────────────────┘
Traffic Flow:
1. App sends request to localhost
2. Sidecar intercepts (iptables rules)
3. Sidecar establishes mTLS connection
4. Traffic encrypted to destination sidecar
5. Destination sidecar decrypts
6. Destination sidecar forwards to app
PeerAuthentication Modes:
1. PERMISSIVE (default initially)
- Accepts both plaintext and mTLS
- Good for migration
2. STRICT
- mTLS required for all traffic
- Rejects plaintext connections
3. DISABLE
- Disable mTLS (not recommended)
Example Policy:
apiVersion: security.istio.io/v1beta1