01 · The production question
If Cloudflare protects the public edge, why does Kubernetes still need Istio and Envoy?
I answered this with runtime evidence rather than a product comparison. During one observation window, automated scanners tested sensitive and malformed paths against public applications. The useful question was not simply “was there an attack?” It was: where did each request stop, what did it consume, and what can each layer prove?
Cloudflare protects the origin at internet scale. Istio and Envoy protect and explain traffic at cluster scale. The application protects identity, business rules, and data. These are adjacent boundaries, not interchangeable products.
02 · One request, four owners
The request changes meaning as it crosses boundaries
03 · What Istio and Envoy actually do
Istio distributes intent; Envoy applies it to live traffic
Istio is not the proxy that handles every request. istiod is the control plane: it watches Kubernetes and Istio configuration, validates policy, issues workload certificates, and translates desired behavior into xDS configuration. Envoyis the data-plane proxy that receives that configuration and applies it to connections.
04 · Evidence, not assumptions
The dashboard separated four very different outcomes
Stopped by edge policy
Envoy returned 403 before a frontend or backend workload was selected.
Rejected during normalization
Malformed paths received 400 at the cluster boundary.
Reached the frontend
Suspicious paths were routed but returned 404 instead of protected content.
Classified by the API
The backend identified automated clients that reached an application endpoint.
Volume changes the control, not the diagnosis
At this rate, Cloudflare WAF would reduce origin exposure, but the cluster still needs a policy boundary for traffic that passes the edge or reaches the origin directly. Host-level evidence was anonymized before publication.
05 · Security and capacity
A blocked request is also application work that never happened
A request rejected at the ingress still consumes some network and Envoy capacity, but it does not reserve an application connection, execute framework middleware, allocate a database session, or run a query. Cloudflare can move that rejection even farther outward; Istio provides the cluster-aware fallback and the evidence needed to prove what happened.
Reached is not the same as breached
“Routed upstream” proves that Envoy selected a destination. It does not prove that a sensitive handler ran, protected data was read, or a successful response was returned. Those claims require correlated application logs, traces, response semantics, and data-layer evidence.
06 · What I would improve next
The dashboard closed one question and opened better ones
Move common abuse outward
Enable proxied DNS deliberately, use managed WAF rules, and protect the origin from direct public bypass before restricting origin access.
Test normalization variants
Case changes, percent encoding, and path traversal variants need positive and negative acceptance tests, not an endlessly growing deny list.
Keep policy evidence attributable
Every dashboard decision should link back to the owning Git manifest, Argo application, live object, request ID, and time window.
Measure the protection itself
Gateway saturation, policy latency, false positives, 429 behavior, and application 5xx must be monitored alongside blocked-request counts.
The result is an explainable defense path
I can distinguish traffic that never reached the cluster, traffic rejected by Envoy, traffic routed to a frontend, traffic handled by the backend, and traffic that produced a data effect. That distinction prevents both false confidence and false alarms. More importantly, it turns security from a collection of product names into a chain of owned, observable decisions.