Build a browser on top of an open standard, neglect that standard, then refer to that neglecting as the reason to kill it. This fits that spiderman pointing at spiderman meme perfectly. It's exhausting.
Yes, since NixOS runs on a standard Linux kernel, Qtap will work. I realized that we weren't scanning the nix store for shared libs (eg. OpenSSL) and added that this morning.
Thanks! We're really excited about Qcontrol and what it will be able to provide! The rules in that doc are powered by our Rulekit project https://github.com/qpoint-io/rulekit if you're curious about seeing more.
As far as log sinks, we have stdout right now. We have been working on Fluentbit and will eventually add a bunch more. If you have a request, drop them here!
We also have a services concept which support an "event store" and "object store", where the object store handles artifacts that may contain sensitive data and don't need to be indexed for search/aggregation (this is an S3 compliant store). The event store handles all of the events from connection audit logs (these cover the ip protocol level) to individual http request/response pairs. The event store is a custom API we use and need to write some proper documentation for, stay tuned!
Standard output is all you need. Let a consumer on the other end do the rest of the work. Don’t make supporting every log collector under the sun your problem. Add OTel support if you really feel the need to.
`ecapture` has been around for a while and do a lot of great stuff and a lot of functionality overlaps.
Our aim is to make Qtap extensible and via a plugin system. We have http1/2 streaming capabilities and a plugin engine to run these in what we call a stack. Our goal is to add more protocols, like gRPC in the near future.
We have a few example plugins that do things like report request/response's and push access information to standard out in a console or structure log format. Our Pro version has a few more plugins like the ability to report errors (eg. an AI agent is getting HTTP 429 errors). These can be pushed to a service or log aggregator.
To summarize, we do a lot of the same things that ecapture does. We'd like to be less of a tool and more of a "always running" that ops, opsec, and devs use to answer tough questions. We look forward to open sourcing more of plugins as they mature!
As of today, we don't output pcap or har files though these are additions I'd like to make in the future, they aren't currently on our near term roadmap.
These are all great callouts. We've worked hard to address some of them, some are future endeavours.
To address your points:
1. In our testing, uprobes add a statistically insignificant amount of latency and in comparison to a MITM proxies it's nearly identical to native.
2. True, we're focused on Linux right now. I'm looking forward to exploring Microsoft's eBPF implementation and exploring how we can support the Windows ecosystem.
3. You're right that the technique we are using for OpenSSL will not work for other runtimes. That said, there are other techniques that we've implemented in our Pro offering for the JVM, Go, and NodeJS. Rust is in the works!
Qtap does require root privileges to function as it uses eBPF to hook into kernel and userspace program functions. The good news is it can also be run within a container.
There are some important flags when spinning it up in docker: `--privileged`, `--cap-add CAP_BPF`, `--cap-add CAP_SYS_ADMIN`, and `--pid=host`. These provide access to load eBPF programs, and monitor traffic.
Many deployments use Kubernetes daemonsets where Qtap runs in a container, but monitors all of the traffic on the node. The Qpoint paid offering comes with a Control Plane that produces context specific dashboards so seeing what's happening from a specific container, or pod namespace can provide a lot of insights into your deployments.
I'm honestly not that interested in constant logging or central collection. I think it's a perfectly useful product, but I find it hard to get buy in for that sort of system in the short term.
Supposedly `kubectl debug` does allow you to set a `sysadmin` profile and grant the debug sidecar `privileged` access. I think that would be a neat low cost way to get value out of your product quickly, right when I have an issue, which would maybe help build some organizational trust and goodwill to make the rest of the stack easier to buy.
It would also solve an issue for me that I would really like solving :P
Fair point on -O2 and -O3 optimized bins. We've approached this by building custom bin utils that are optimized for blazingly fast symbol recognition. Traditional ELF tools that focus on providing comprehensive context for debugging, we are strip away everything that is not the symbol locations we need.
We've also added caching so frequently used bins don't require multiple scans. Shared libraries as well. This has proven effective with optimized binaries, especially bins that are optimized, start, make a super quick network call, then exit, which was the bane of our existence for a little while.
