This is a great point, and Qtap itself does need to be used with care. The company behind Qtap (Qpoint.io) provides full inventory and alerting for this sort of scenario.
That said, the eBPF verifier has robust security guarantees and runs on every load. So arbitrary mem access for example isn't possible. Qtap runs exclusively on your nodes, so you control what it captures and where that data goes. Our paid offering provides more functionality with a Control Plane solutions that provides dashboards, alerting, and live config updates. However, all sensitive information, like captured http bodies, are uploaded to a S3 compliant bucket that you control. This could be S3, Minio, or anything else that supports the S3 API. We never see this information.
It's intentionally designed for deployment within your infra and abides by the security policies you set within your org.
>The company behind Qtap (Qpoint.io) provides full inventory and alerting for this sort of scenario.
Could you expand on this? I haven't seen anything on your company website that suggests detection of this kind of stuff. Also, could you explain how this could be detected? Through another eBPF program?
What's the recommended way of locking down communications for this application? With a MITM based solution it's fairly clear you can lock its egress down to precisely what it needs at the network policy level at least, whereas it's a bit trickier with this as it necessarily shares an instance with other processes.
Is uploading clear text encrypted in flight data to another system even a good idea in most cases? In some cases that won't even be allowed because you'd end up storing regulated information in a way that auditors won't approve of (e.g. sometimes there is a requirement for field level encryption when data is in storage/at rest)
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.
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.