Solving Multi-Service Without a Service Mesh
summary
Kubernetes primitives can replace a mesh but require work: use cert-manager or a self-signed cluster-local CA for intra-cluster TLS, rely on token projection (audiences) not raw service account tokens, and combine NetworkPolicy + API Gateway for rate limits and multi-tenant routing. Practical problems include mounting CA certs into arbitrary containers (OpenSSL hashes, Java keystores), opaque CNI encryption/NetworkPolicy enforcement, Envoy CPU cost for sidecars, and SPIFFE/spiffy integration trade-offs — choices trade convenience for control.
AI-written summary · about
chapters (13)
- 0:00Start
- 1:31What About Security?
- 4:33Service Identity
- 5:02ServiceAccounts to the Rescue
- 5:27Token Projection for Identity
- 7:00Avoiding Bearer Tokens
- 7:45Converting An Auth Problem To a Key Distribution Problem
- 8:18Loading CA Certificates
- 12:19Tricks for Multi-Tenant Services
- 16:17You May Need These and a Mesh
- 19:40API Gateway Mesh?
- 20:32Layered Payloads
- 22:27Everything Is Awesome
related talks
28mService Identity - The Key to Zero Trust with Service Mesh
50mMulti-Cluster Kubernetes and Service Mesh Patterns
05mBest Practices on Setting up Multi Cluster Service Mesh in AWS
29mZero Trust Security with Service Mesh
01h 03mJust what is a "service mesh", and if I get one will it make everything OK?
25mAdministering Multi Cluster Service Meshes Securely
10mService Mesh Security in a Nutshell
31mHow We Solved TLS at Scale: Self-Service, Multi-Tenant Cert-manager