Add new "tracee" command

[yanivagman]

The current entrypoint of the tracee container is entrypoint.sh. This is a simple bash script that starts both tracee-ebpf and tracee-rules, and connects them with a pipe. Although simple, this approach has several drawbacks:

1. It doesn't support passing capture flags (as well as other tracee-ebpf specific flags)
2. It is written in bash and not in go, making it less testable and impossible to use existing go packages (but binaries)
3. It is required to signal readiness of tracee-ebpf before starting tracee-rules (#930)

Now that we restructured the repo, we can start talking about adding a new (go) command that will be the entrypoint, called "tracee". As a first step, this command can mimic entrypoint.sh functionality by spawning two new processes, and executing tracee-ebpf, then tracee-rules. Later, we can combine the flags of tracee-ebpf and tracee-rules, creating a more user friendly interface for interacting with tracee, while still giving the flexibility of using any flag of these two.

[rafaeldtinoco]

I'm preparing a "mid-term" (that won't solve this issue) change allowing one to execute "Makefile.one" based containers for "tracee-ebpf" and "tracee" (tracee-ebpf + tracee-rules) using shell entrypoints. I believe this effort will be a continuation of changes made by https://github.com/aquasecurity/tracee/pull/1273.

[itaysk]

This is a good opportunity to aggregate top-level management functionality such as configuration, and observability. I was thinking to have some kind of "tracee-manager" to hold the HTTP server needed to expose stats, or receive commands, but actually this "tracee" executable is a better place to implement this. related: #636 #887

[josedonizetti]

@yanivagman @rafaeldtinoco This is still something on the plans? Having a single binary would be better for the kubernetes deployment. Because to configure a liveness probe for kubernetes (so k8s knows tracee is healthy) checking two different process is a little odd. I was actually considering changing k8s kubernetes to instead of having one container, have two containers one for tracee-ebpf and another for tracee-rules and instead of a pipe, configure the communication to be unix sockets. So we would have one livenessprobe per container. But if moving into single binary is an option, I think i prefer a single binary.

[yanivagman]

@yanivagman @rafaeldtinoco This is still something on the plans?

Definitely.

[rafaeldtinoco]

And, for now, we're also thinking on: https://github.com/aquasecurity/tracee/issues/2038 to make end user (docker container) life easier.

[rafaeldtinoco]

I was actually considering changing k8s kubernetes to instead of having one container, have two containers one for tracee-ebpf and another for tracee-rules and instead of a pipe, configure the communication to be unix sockets.

Yep, when were studying protobuf we say its limits using unix sockets and that seemed pretty enough. For your effort, consider a constant throughput of ~20MB/s in between the two (above what we currently have, but a good "idea" for your plans if you need to know the throughput).

[geyslan]

These changes require discussion of CLI UX. Do you have plans for what would be the next generation of tracee flags (read: syntax)? I'm bringing this up because we're focused on enabling flags in sets.

[josedonizetti]

Due to multiple conflicts, and way too many changes for the same PR. I'm breaking this down in multiple issues and prs. It will simplify reviewing, and also keeping tracking of changes with main.

• https://github.com/aquasecurity/tracee/issues/2236
• https://github.com/aquasecurity/tracee/issues/2240 ...

[josedonizetti]

This is getting implemented at https://github.com/aquasecurity/tracee/issues/2355