Shh, It is A Secret: Manage Your Workload Certs in Service Mesh without Persisting any Secrets- Lin Sun, Solo.io
Talkat ServiceMeshCon Europe 2022 · on Tuesday, 2022-05-17· at 10:30· Pavilion 3 | Room D | Level 2 | Central Forum·
summary
Istio’s default uses a self‑signed root secret that stores a private key in a Kubernetes Secret (root CA lives 10 years, workload certs 24 hours with a 12‑hour rotate), which many orgs reject. Options: provide an external CA secret (still persists the key), use cert‑manager via istio‑csr (Istio acts as RA, cert‑manager as CA — keys still end up as Secrets), adopt kubernetes CSR integration to avoid persisting private keys, or run a signing sidecar that keeps intermediate keys out of the cluster.
AI-written summary · about
chapters (12)
- 0:00Intro
- 0:35Lins background
- 1:29Introduction
- 2:24How it works
- 9:20Search
- 12:26Registration Authority
- 13:03Seocsr
- 14:23Kubernetes CSR
- 15:20How this approach works
- 19:08Another Approach
- 20:28One Last Approach
- 23:08Conclusion
related talks
19mIdentity, Istio, And You
30mIstio New Workload Identity Provision Pipeline Based on Envoy SDS
42mSecuring Kubernetes Workloads with Istio Service Mesh
32mIstio: Sailing to a Secure Services Mesh
15mCertificates in Kubernetes
36mCertifik8s: All You Need to Know About Certificates in Kubernetes
24mCan You Keep a Secret? On Secret Management in Kubernetes
28mService Identity - The Key to Zero Trust with Service Mesh