Tracee Architecture Overview¶
Kernel eBPF programs GENERATE Tracee Events to Userland:
- Trafic Control Hooks
Userland events are COLLECTED and ENRICHED with more information:
- Kernel Events (Syscalls, Tracepoints, Kprobes)
- OS Events (Running Containers, ...)
- Derived (from other) Events
- Network Events
DETECT patterns based on existing signatures:
- OPA/Rego signatures
- Golang signatures
- Go-CEL signatures (Proof-of-Concept / Experimental)
Let other tools to CONSUME detection events:
- Work in Progress
Tracee Pipeline Concept¶
Multiple CPUs constantly generate events from the eBPF programs running inside the kernel (inside an eBPF VM).
The eBPF programs are executed whenever the kernel (or network) hooks they're attached to are triggered.
eBPF programs decide whether they should submit the events to tracee-ebpf or not, based on given filters.
Those events are sent to libbpfgo through a shared memory ring buffer mechanism (called perfbuffer).
libbpfgo sends collected events to tracee through golang channels.
tracee-ebpf parses received events and does multiple things:
- parse events for argument type conversions if requested
- enriches the events that need enrichment (containers, network, processes)
- capture artifacts from collected events into external files
tracee-ebpf writes events to tracee-rules through a mechanism called printer.
tracee-rules receives events and evaluate them using either golang or rego (or go-cel, as a proof-of-concept) signatures.
- Golang signatures are faster and do pretty much anything the language allows. They might connect (or have cached) external data sources to evaluate events, for example.
Detections are spit out from tracee-rules if evaluations are positive.
This mechanism is what we call the tracee pipeline: to receive events from the kernel into userland (tracee-ebpf), then to parse and enrich those events and to submit them to tracee-rules for it to evaluate them looking for detection patterns described as signatures.