( Updated after comments and findings from my colleague Joel )

When you use Istio and potentially have Kiali installed, you may see that sometimes data comes from ‘unknown’:

Don’t worry — this is not a hacker sending data to your services. It is most likely that Istio records traffic to your services and workloads that did not come from a source pod that has the Envoy proxy deployed and is thus not part of the Mesh.

Ingress traffic

Istio expects traffic to go via the the Ingress Gateway. When you see ‘unknown’ traffic it can simply be the case that you use the standard Kubernetes Ingress or an OpenShift route to send traffic from the outside to Istio.

You may think that this is not an issue, as the traffic arrives at your service and then from there is also part of the mesh. This is mostly true.

But you also miss the opportunity for traffic control, header rewriting, mutualTLS between Ingress GW and the service.

Internal traffic

The other source of traffic from ‘unknown’ are (normal) pod inside the (Kubernetes) cluster that do not have the Envoy sidecar deployed and which are thus not part of the mesh.

For example calls to /health or /metrics in your app from the kubelet or Prometheus may be provoking this.

You can filter this traffic out the by modifying an Istio-config rule by adjusting the match clause (the part about kube-probe may already be present depending on the Istio version:

$ kubectl edit rules.config.istio.io promhttp -n istio-system



[...]

match: (context.protocol == "http" || context.protocol == "grpc") &&

(match((request.useragent | "-"), "kube-probe*") == false) &&

(match((request.useragent | "-"), "Prometheus*") == false)

There is an open PR for Istio on this.

Dealing with ‘unknown’ traffic

Over time you want migrate all services on to the mesh. If you are worried about this unknown traffic, you can also use Istio Rules to blacklist that traffic.