[delusional]

What does the usage pattern look like for this. Will I need to be root to run it, and can it run from inside a container without "real" host root?

I'm always looking for a way to make sniffing traffic from inside a container easier, and if I could attach a debug sidecar with something like an eBPF based SSL pre-master key extractor (both on incoming and outgoing requests) it starts to feel a lot like having network JTAG.

[jonfriesen]

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.

[delusional]

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