Disrupting Malicious Traffic with Egress Proxies
summary
Lyft builds an Envoy-based egress gateway that forces outbound traffic through a client-aware CONNECT proxy with a transparent iptables sidecar to trap leaky traffic, enforcing per-service allowlists (about ~1,000 services mapped to upstream domains). Rollout uses shadow-deny then enforcement; observed p99 latency increases ~10 ms from tunnel setup. Design blocks DNS exfiltration, scales with dedicated EC2 Envoy clusters behind ASGs, produces richer telemetry for detection, and prevents many runtime payload downloads and unauthorized upstream connections.
AI-written summary · about
chapters (12)
- 0:00The importance of egress
- 1:45Organizational challenges
- 2:40Technical hurdles
- 4:22Initial design attempts
- 5:28The Envoy-based architecture
- 7:34Connect and transparent proxy
- 10:43Internet gateway strategy
- 13:06The connect proxy workflow
- 14:40Transparent proxy workflow
- 17:41Rollout and operationalization
- 20:27Performance and benefits
- 22:56Q&A session
related talks
36mSecuring Every Bit
31mEnvoy Project Intro – Matt Klein & Jose Nino, Lyft
23mUsing Envoy as an Egress Proxy for TLS Enabled Traffic
38mPanel Discussion: Ask Us Anything: Microservices and Service Mesh
11mA decade of Envoy: From Lyft's Debugging Nightmare to the AI Infra...
34mHow Many Proxies Do You Need?
48mProxies, Gateways, and Service Mesh. Why Are Words so Confusing?
35mEnvoy Maintainer Q+A