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.
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.
>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?
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.
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.
2 replies →
>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?
My first thought was this is cool. My second thought was that this is going to be impossible to securely manage and administer.