(Almost) Secure by Default - Next Steps for Hardening Istio in Production...
summary
Istio defaults to permissive mTLS so attackers or misconfigurations can bypass cluster-wide encryption; set strict mTLS and enforce it with policy tools because workload and namespace-level peerAuthentication/destinationRule wins can undo global settings. Deploy Ingress/Egress gateways in separate namespaces, set outbound traffic policy: REGISTRY_ONLY, originate TLS at gateways, and use a WAF (Coraza WASM) plus Envoy filters for rate limiting. Replace the init CNI with the chain CNI and move root keys to Azure Key Vault or an external CA; Gatekeeper blocks risky overrides and logs plus Argo CD detect drift.
AI-written summary · about
chapters (16)
- 0:00Istio security intro
- 1:03Why Istio is almost secure
- 3:29Zero trust for Istio
- 4:54Auth and encryption in Istio
- 7:06Preventing policy bypass
- 8:32Authorization best practices
- 9:55End user auth at ingress
- 11:00Securing edge traffic
- 13:05Managing egress securely
- 15:15Certificate management
- 17:41Gatekeeper for policies
- 19:10Visibility and telemetry
- 20:35Workload and image security
- 21:58Defense in depth overview
- 23:24Live hardened Istio demo
- 28:37Closing and Q&A
related talks
46mContinuous Kubernetes Security
44mTutorial: Hacking Istio: The Good, the Bad, and the Misconfigured
10mBest-Practices for Securing Egress Traffic with Istio
38mEmbracing the Future: The Effortless Mutual TLS and Rich Layer 7 Authz Policy Without Sid...
32mIstio: Sailing to a Secure Services Mesh
31mEncryption, Identities, and Everything in Between; Building Secure Kubernetes Networks
10mService Mesh Security in a Nutshell
42mSecuring Kubernetes Workloads with Istio Service Mesh