5 Istio misconfigurations that istioctl analyze won't catch

Istioctl analyze is a popular tool for validating Istio configurations, catching issues such as unknown hosts, missing Services, and malformed specs. However, it does not catch configurations that parse correctly but cause traffic issues at runtime. Here are five common misconfigurations that istioctl analyze fails to detect:

1. No mTLS enforcement: A namespace without PeerAuthentication is in PERMISSIVE mode by default, allowing both plaintext and mTLS traffic. If no PeerAuthentication policy is added, plaintext traffic can enter the namespace silently, which istioctl analyze does not flag. To prevent this, a PeerAuthentication policy with mtls mode set to STRICT should be configured.

2. VirtualService with retries but no timeout: A VirtualService with retries specified but no top-level timeout can lead to extended upstream load if the upstream service is slow or stuck. For example, a VirtualService with three retry attempts and a perTryTimeout of 5 seconds can cause a 15-second load on the upstream for a single slow request. It is important to set a timeout, such as 10 seconds, to mitigate this issue. Istioctl analyze does not check for this timeout configuration.

3. DestinationRule without outlier detection: A DestinationRule without outlier detection does not automatically eject degraded pods from traffic rotation. Kubernetes readiness probes handle obvious cases, but degraded pods that still pass health checks can remain in rotation. Adding outlier detection with metrics like consecutive5xxErrors, interval, and baseEjectionTime can help catch and handle such situations. Istioctl analyze does not validate the presence of outlier detection configurations.

4. Pods running without Istio sidecar: Pods without the Istio sidecar (istio-proxy) are outside the mesh and lack mTLS encryption and telemetry. This can occur when a Deployment has sidecar.istio.io/inject set to false, a pod was created before injection was enabled, or an operator or Job runs with injection disabled. Such pods will receive traffic but won't be mTLS-encrypted, and VirtualService routing rules won't apply to their outbound traffic. Istioctl analyze does not detect the absence of Istio sidecar in pods.

5. EnvoyFilter without workloadSelector: EnvoyFilters are powerful but dangerous Istio primitives. A misconfigured EnvoyFilter without a workloadSelector applies to all pods in the namespace, potentially affecting the entire mesh if the filter is in the istio-system namespace. Istioctl analyze only validates the structure of EnvoyFilter patches, not the impact on the entire cluster. To avoid this, a workloadSelector should be specified to limit the EnvoyFilter's scope.