istioctl analyze is a syntax check, not a safety gate

A dev.to post walks through five Istio configurations that pass `istioctl analyze` and then break traffic at runtime ^[1][2]. It matters because analyze is the tool most teams reach for when they want a validation step, and the failures it misses arrive with no schema violation and no warning: silent failures, or 503s that are hard to trace back ^[1][2].

Start with mTLS. A namespace with no PeerAuthentication runs in PERMISSIVE mode, so the sidecar accepts plaintext as readily as mTLS ^[3]. Analyze reports nothing, because no policy at all is a valid configuration ^[4]. The absence is the bug: a namespace ships, nobody adds the default STRICT policy, and unencrypted traffic enters it silently ^[5][6]. Any statement of the form "mesh traffic is encrypted" is, in that state, an assumption.

The retry example is the one to put in front of your on-call. A VirtualService with `attempts: 3` and `perTryTimeout: 5s` and no top-level timeout lets each attempt burn the full five seconds, so one slow client request becomes up to 15 seconds of upstream load ^[7]. Three hops configured the same way, with a stuck dependency underneath, is 45 seconds of retry storm traceable to a single request ^[8]. The post's fix is a 10s timeout with three attempts at 3s ^[9], which caps retries at 9 seconds inside a 10-second budget, about a third off the unbounded figure ^[11]. Analyze has no opinion on the combination ^[10].

The other three are variations on the same theme. A DestinationRule that sets `maxConnections` but no outlier detection is valid and leaves degraded-but-live pods in rotation, because readiness probes catch the pod that crashes, not the pod that passes every probe while returning 500s or crawling ^[12][13]. Outlier detection keys on observed error rates instead, with a threshold of five consecutive 5xx, a 10-second interval and 30 seconds of ejection in the post's example ^[14]; analyze says nothing about its absence ^[15]. A pod with no `istio-proxy` is outside the mesh entirely, with no mTLS and no telemetry ^[16], which happens via an `inject: "false"` annotation, a pod created before injection was enabled and never restarted, or a Job started with injection off ^[17]. It still receives traffic, unencrypted, and VirtualService rules do not apply to what it calls out to ^[19]; analyze does not flag it, because the pod runs and the config is valid ^[18]. An EnvoyFilter with no `workloadSelector` patches every pod in its namespace, or every pod in the mesh if it lands in `istio-system` ^[20]. The author says selector-less patches have taken down whole clusters ^[21]; analyze validates the patch structure, not the blast radius ^[22].

The post closes with a tool the author wrote, meshscan, which reads a cluster's Istio resources and reports semantic misconfigurations, per namespace or cluster-wide, with JSON output for pipelines ^[23][25]. Read the sample report as a specification rather than a product claim: missing PeerAuthentication critical, missing outlier detection and retry-without-timeout high, a VirtualService with no matching DestinationRule medium ^[24]. Three of the five failure modes described in the article appear as checks in that sample; the sidecar-less pod and the unscoped EnvoyFilter do not ^[26].

The lesson does not depend on the tool. A schema validator answers whether a document is well formed, and all five of these are well formed ^[2]. The questions worth answering are stateful and negative: whether this namespace has a PeerAuthentication, whether every pod in it carries a sidecar, whether every VirtualService with retries also carries a timeout, whether every EnvoyFilter has a selector. Those are assertions against a running mesh, and they need to run on a schedule as well as in CI, because namespaces get created long after the pull request merges ^[6]. If analyze is your only gate, describe it accurately in your controls documentation: a syntax check.