← Week 3: Service Mesh & mTLS

Day 18: mTLS in Service Mesh — SPIFFE/SPIRE

Phase 3 · Jul 18, 2026

← Week 3: Service Mesh & mTLS

Agenda (2–3 hours)

  • Read (45 min): SPIFFE spec (RFC-style); SPIRE documentation; Istio security documentation on peer authentication
  • Study (45 min): Map the SPIFFE identity model to the AWS model (IAM roles); what does spiffe:// URI represent?
  • Practice (45 min): Enable STRICT mTLS in Istio; verify that plain HTTP between two services is rejected; inspect the SVIDs in use with istioctl
  • Challenge (30 min): How would you federate two SPIFFE trust domains (e.g., Istio mesh + standalone SPIRE)? What do the federation bundles contain?
← Week 3: Service Mesh & mTLS

SPIFFE: Secure Production Identity Framework

SPIFFE solves: "how does service A prove its identity to service B, without API keys or passwords?"

SPIFFE ID: a URI identifying a workload:

spiffe://trust-domain/path/to/workload
spiffe://cluster.local/ns/production/sa/payments-service
spiffe://acme.corp/region/us-east-1/service/api-gateway

SVID (SPIFFE Verifiable Identity Document): a certificate or JWT carrying a SPIFFE ID

  • X.509 SVID: standard X.509 cert with SPIFFE URI in the SubjectAltName extension
  • JWT SVID: a JWT with sub set to the SPIFFE ID
← Week 3: Service Mesh & mTLS

SPIRE: The SPIFFE Runtime Environment

SPIRE implements SPIFFE for production environments:

┌─────────────────┐     ┌──────────────────┐
│  SPIRE Server   │     │   SPIRE Agent    │
│                 │◄────│  (on each node)  │
│  - Issues SVIDs │     │  - Attests node  │
│  - Manages keys │     │  - Issues SVIDs  │
│  - Federation   │     │    to workloads  │
└─────────────────┘     └──────────────────┘
                               │
                         UNIX domain socket
                               │
                         ┌─────────────┐
                         │  Workload   │
                         │  (svc A)    │
                         └─────────────┘
← Week 3: Service Mesh & mTLS

PeerAuthentication: Enforce mTLS

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT

STRICT: all traffic into the namespace must be mTLS — plain HTTP is rejected.
PERMISSIVE: accept both mTLS and plaintext (migration mode).
DISABLE: no mTLS requirement.

AuthorizationPolicy: add RBAC on top:

spec:
  action: ALLOW
  rules:
  - from: [{ source: { principals: ["cluster.local/ns/payment/sa/checkout"] } }]
    to: [{ operation: { methods: ["POST"], paths: ["/v1/charge"] } }]
← Week 3: Service Mesh & mTLS

Trust Domains and Federation

A trust domain is a namespace for SPIFFE IDs: spiffe://<trust-domain>/...

Multiple meshes or organizations with separate trust domains can federate:

  1. Each trust domain publishes its trust bundle (root CA certs)
  2. SPIRE Server exposes BundleEndpoint for federation
  3. Partner SPIRE Servers poll each other's endpoints to get updated root CAs
  4. Services in domain A can authenticate services in domain B using federated bundles
← Week 3: Service Mesh & mTLS

Key Takeaways

  • SPIFFE provides workload identity via URI-based IDs in X.509 SANs
  • SPIRE implements SPIFFE for Kubernetes and VM workloads
  • Istio Citadel IS a SPIFFE implementation — uses SPIFFE SVIDs for all mTLS
  • STRICT PeerAuthentication + AuthorizationPolicy = zero-trust networking within the mesh

Tomorrow: traffic management — retries, fault injection, and weighted routing in Istio.