Falco works by taking Linux system call information at runtime, and rebuilding the state of the kernel in memory. The Falco engine depends on a driver in order to consume the raw stream of system call information. Currently the Falco project supports 3 different drivers in which the engine can consume this information.
This blog will highlight the nuances of each implementation and explain why they exist. Hopefully this resource will give you a starting point for understanding which driver is right for your use case.
Updated: Falco 0.26.0
The Falco Kernel module is the traditional way of consuming the required stream of data from the kernel.
Source: github.com/draios/sysdig/driver
The kernel module must be loaded in order for Falco to start.
The kernel module depends on the linux-headers
package in order to compile. More information
.
Note: A convenience script found here
cd ~
git clone git@github.com/falcosecurity/falco
cd falco
mkdir build
cd build
cmake ../ \
-DBUILD_BPF=OFF \
-DBUILD_WARNINGS_AS_ERRORS="OFF" \
-DCMAKE_BUILD_TYPE="Release" \
-DCMAKE_INSTALL_PREFIX="/usr" \
-DFALCO_ETC_DIR="/etc/falco" \
-DUSE_BUNDLED_DEPS=ON
make driver
sudo insmod driver/falco.ko
sudo falco
The kernel module is the most commonly used driver for Falco and can be used in any environment where loading a kernel module is trusted and viable.
Kernel modules are the quickest, and most common way to run Falco. They are a viable solution in any environment where access to the host kernel is trusted.
The Falco eBPF probe is a viable option in environments where kernel modules are not trusted or are not allowed but eBPF programs are. The most common example of this environment is GKE. Running Falco in GKE was the original use case for creating the eBPF probe.
Source: github.com/draios/sysdig/driver/bpf
The eBPF probe must be loaded in order for Falco to start, and will provide the same stream of metrics that the kernel module does. Falco should work seamlessly with this approach.
Note: Notice the -DBUILD_BPF=ON
flag
Note: A convenience script found here
cd ~
git clone git@github.com/falcosecurity/falco
cd falco
mkdir build
cd build
cmake ../ \
-DBUILD_BPF=ON \
-DBUILD_WARNINGS_AS_ERRORS="OFF" \
-DCMAKE_BUILD_TYPE="Release" \
-DCMAKE_INSTALL_PREFIX="/usr" \
-DFALCO_ETC_DIR="/etc/falco" \
-DUSE_BUNDLED_DEPS=ON
make bpf
cp driver/bpf/falco.o ${HOME}/.falco/probe.o
sudo falco
dkms
, modprobe
, or insmod
to load the program.The eBPF probe should be used when loading a kernel module is not a viable option. Reasons for not loading a kernel module may change, and in this case the eBPF probe is the default.
The pdig
binary is the newest and most viable path forward when both a kernel module, and eBPF probe is not an option.
The most common example of this environment is AWS ECS with Fargate.
The pdig
tool is built on ptrace(2)
. It requires CAP_SYS_PTRACE
enabled for the container runtime.
The pdig
tool enables a new way of consuming metrics about a given application at the process level.
Note: The eBPF probe and kernel module work at a global host level, whereas pdig
works at a process level. A clever invocation of pdig
against a system can simulate a broader scope of system parsing. PID 1 is sometimes of interest.
Source: github.com/falcosecurity/pdig
ptrace(2)
is slow. Period.pdig
binary to "hack" the driver.The pdig
tool is the most unique of all the drivers, and enables functionality not otherwise possible.
Solution | Suggested Driver | More Resources |
---|---|---|
Baremetal Kubernetes | Kernel Module | Helm Chart |
Kubeadm Kubernetes | Kernel Module | Helm Chart |
Kubernetes Kind | Kernel Module | Kind Documentation |
Minikube | Kernel Module | Minikube Documentation |
AWS EKS | Kernel Module | Helm Chart |
Azure | Kernel Module | Helm Chart |
GKE | eBPF Probe | Falco on GKE |
IBM Cloud | Kernel Module | Helm Chart |
OpenShift | Kernel Module | Helm Chart |
AWS ECS | pdig | pdig falco-trace |
AWS EKS (Fargate) | pdig | pdig falco-inject |
ARM/Raspberry PI | eBPF Probe *Kernel specific |