Architecture¶
Tracee Architecture Overview¶
Overview
-
Kernel eBPF programs GENERATE Tracee Events to Userland:
- Tracepoints
- Probes
- 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:
-
Let other tools to CONSUME detection events:
-
ENFORCE
- Work in Progress
Tracee Pipeline Concept¶
Pipeline
-
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 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 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 writes events to tracee-rules through a mechanism called printer.
-
tracee-rules receives events and evaluate them using either golang or rego 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), 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.