You've definitely hit on a point that we've talked about at length and have come to terms that different organizations have different requirements, especially when it comes to regulatory and compliance.

Qtap can be locked down with local firewalls or perimeter firewalls like other applications running within a network. The TLS inspection can also be disabled with a `--tls-probes=none` flag on startup.

Even without inspection enabled, Qtap provides rich context when it comes to connections to processes. For example, source/destination information, bandwidth usage, SNI information, container meta, even Kubernetes pod and namespace meta. All of this can paint a thorough picture of what's happening with zero instrumentation.

When it comes down to it, some orgs may not be able to use the TLS inspection or require specific methods of persisting data. If we can't support this today, our goal is to address these as they come up and hopefully help devs and ops folks working in these constrained environments get what they need while maintaining compliance.

Your writing style reminds LLM for some reason.

I imagine one challenge you’ll face is how to keep it configurable and flexible prior to any data leaving the system. For example, you’d like to default to “intercept everything,” but also allow the user to define rulesets for which packets to ignore or include. That would be a nicer UX with an application-level tool, but at that point you’ve already exfiltrated the data they want to filter. So you’ll need a rules engine that can execute locally in the eBPF program, but now that program is becoming much more complicated.

Also worth noting this is very similar to the code path that got Crowdstrike in trouble when they crashed every device on the internet because of a bug in the parser of their rules engine.