Securing Kubernetes with Istio
summary
Istio deploys an Envoy sidecar proxy per pod (injected via kube-inject) and uses an init container with NET_ADMIN iptables redirection so app traffic transparently goes through the proxy; Citadel acts as a CA and issues short-lived certificates (default 1 hour, refreshed every 30 minutes) stored as Kubernetes secrets that can be mounted into apps. It enforces mutual TLS for service-to-service auth, supports JWT-based end-user checks and policy-based authorization, but has had timing and proxy bugs in early releases.
AI-written summary · about
chapters (18)
- 0:00Introduction to speaker
- 0:49Kubernetes container threats
- 2:38What is Istio service mesh?
- 4:30Istio security architecture
- 6:16Envoy proxy capabilities
- 8:08Istio control plane components
- 10:06Traffic hijacking mechanism
- 13:05Injecting proxies into pods
- 17:58Traffic policies and MTLS
- 18:57SPIFFE identity framework
- 23:04Istio Citadel and certificate
- 27:55Authentication and authorization
- 30:43End-user JWT validation
- 34:24Using certificates without sidecars
- 37:43Security risks and bugs
- 39:46Service mesh versus app servers
- 40:52Istio installation and resources
- 44:28Q&A and closing remarks
related talks
42mSecuring Kubernetes Workloads with Istio Service Mesh
32mIstio: Sailing to a Secure Services Mesh
35mIoK: Istio-on-Kubernetes Deep Dive [I]
34mFrom Kubelet to Istio: Kubernetes Network Security Demystified
34mEnvoy SDS: Fortifying Istio Security
43mService Mesh for developers
32mIstio: Weaving the Service Mesh [I]
48mIstio An open platform to connect, manage, and secure microservices