You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
I am working on Corsha's CAST project, which is an API security tool for analyzing Kubernetes API traffic for authentication vulnerabilities such as reused credentials, traffic from outside the service mesh (Istio) using Istio-signed certificates, etc. https://github.com/corshatech/cast
We are interested in seeing both:
App-to-App traffic within an Istio service mesh
Istio’s control plane traffic such as CSRs
I found this closed issue to ensure that Istio is supported by Kubeshark, but there isn't much info in the ticket: #1398.
Running Istio's Bookinfo demo application, starting a Kubeshark tap (kubeshark tap --tls), then generating traffic to the app, I have successfully observed app-to-app traffic within Istio:
However, I have been unable to capture any Istio control plane traffic so far. (The Istio control plane manages and configures the proxies to route traffic, so I have had Kubeshark tapping traffic while the app is being set up, torn down, or otherwise modified, but with no success.)
I filtered out the health-checking and readiness-probe traffic by applying this filter in the Kubeshark UI: !dns and request.path != "/-/ready" and request.path != "/healthz/ready" and request.path != "/stats/prometheus" and request.path != "/-/healthy" and request.path != "/ready" and request.path != "/health" and request.path != "/api/health" and request.path != "/metrics" and request.path != "/kiali/healthz" and request.path != "/api/v1/query_range" and request.path != "/app-health/loki/readyz" and dst.name != "jaeger-collector". Then, with Kubeshark already tapping all pods in all namespaces within the k8s cluster (kubeshark tap --tls), I spun up, modified, and tore down the demo application, all the while observing no traffic at all (other than the traffic from rendering the webpage from the demo app).
I would love to know if y'all have any suggestions for me on how to proceed.
Original Thread
No response
Describe the solution you'd like to see
I would like to know definitively whether this feature gap (the ability to observe Istio control plane traffic through Kubeshark) is known and/or intended. If not, I would love to hear any suggestions that y'all might have for me to successfully capture this traffic data.
@katieatcorsha thanks for your detailed note! Kubeshark deals with Envoy/Istio in a much different way than it does a cluster without Envoy. We never tried to capture Istio control plane traffic. It doesn't mean that we can't, we simply didn't put any focus on that. I'd love to better understand your use case and see if we can address it. Feel free to reach out to me on Slack to continue this discussion.
Contact Details
katie@corsha.com
Is your feature request related to a problem? Please describe.
I am working on Corsha's CAST project, which is an API security tool for analyzing Kubernetes API traffic for authentication vulnerabilities such as reused credentials, traffic from outside the service mesh (Istio) using Istio-signed certificates, etc.
https://github.com/corshatech/cast
We are interested in seeing both:
I found this closed issue to ensure that Istio is supported by Kubeshark, but there isn't much info in the ticket: #1398.
Running Istio's Bookinfo demo application, starting a Kubeshark tap (
kubeshark tap --tls
), then generating traffic to the app, I have successfully observed app-to-app traffic within Istio:However, I have been unable to capture any Istio control plane traffic so far. (The Istio control plane manages and configures the proxies to route traffic, so I have had Kubeshark tapping traffic while the app is being set up, torn down, or otherwise modified, but with no success.)
I filtered out the health-checking and readiness-probe traffic by applying this filter in the Kubeshark UI:
!dns and request.path != "/-/ready" and request.path != "/healthz/ready" and request.path != "/stats/prometheus" and request.path != "/-/healthy" and request.path != "/ready" and request.path != "/health" and request.path != "/api/health" and request.path != "/metrics" and request.path != "/kiali/healthz" and request.path != "/api/v1/query_range" and request.path != "/app-health/loki/readyz" and dst.name != "jaeger-collector"
. Then, with Kubeshark already tapping all pods in all namespaces within the k8s cluster (kubeshark tap --tls
), I spun up, modified, and tore down the demo application, all the while observing no traffic at all (other than the traffic from rendering the webpage from the demo app).I would love to know if y'all have any suggestions for me on how to proceed.
Original Thread
No response
Describe the solution you'd like to see
I would like to know definitively whether this feature gap (the ability to observe Istio control plane traffic through Kubeshark) is known and/or intended. If not, I would love to hear any suggestions that y'all might have for me to successfully capture this traffic data.
Provide additional context
More details on our project and what we are overall trying to achieve: https://github.com/corshatech/cast#cast
Some info on how we use Kubeshark: https://github.com/corshatech/cast#kubeshark
Code of Conduct
The text was updated successfully, but these errors were encountered: