Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upKernel event tracing owned and maintained by Falco #976
Comments
This comment has been minimized.
This comment has been minimized.
|
I know @leodido has spent the most time on this, and will be one of the engineers in charge of owning and maintaining this for Falco |
This comment has been minimized.
This comment has been minimized.
|
So I was hacking on some BPF things today and started to explore something with Go It doesn't actually do anything but it's an idea that we might want to look at: https://github.com/kris-nova/barff Thoughts/feedback appreciated as always. |
This comment has been minimized.
This comment has been minimized.
|
This project also relies heavily on libscap and libsinsp - https://github.com/sysflow-telemetry/sf-collector It might be interesting to talk to them about their plans for these two libraries and see if there's shared work that could happen between sysdig, IBM, and the falco community. |
Motivation
Following up on discussion from last weeks call regarding the new Falco API and composable inputs. We had some questions come up from members of the CNCF so documenting our plan with the Falco API and how that will enable us to port the kernel module and eBPF probe functionality directly into the Falco security github org.
As it stands there are 4 main input streams being plumbed through Falco that a user can turn on or off.
libscapandlibsinspand either a kernel module or eBPF probeThe current approach is to compile these input mechanisms directly into Falco.
Following design discussion on the weekly Falco planning calls, and discussions in person at Kubecon we have learned that there are other use cases for input streams into Falco.
One such use case is discussed here in this Kubecon video from a production Falco user
Feature
The proposal for the input API mechanism was discussed in this proposal: https://github.com/falcosecurity/falco/blob/dev/proposals/20191030-api.md
As the input stream proposal is finalized, we would like to take ownership of various kernel modules and the eBPF probes used to extract events from the kernel, and refactor the architecture so we can now store the driver and probe source code directly in Falco.
This design enables existing users of Falco to continue to use kernel drivers and eBPF probes arbitrarily.
The Falco OSS project will ultimately independently own and maintain kernel tracing components directly in the Falco security github org
Alternatives
As a community we need to decide the implementation of taking ownership of these components. There is existing work in the
sysdigCLI tool we could use to get started, or we can write a new driver. There are pros and cons to each approach and ultimately we as a community need to decide what is best.This design enables vendors to continue to use Falco as it stands currently, while enabling the community to engineer and maintain all dependencies indepentely.
Additional context
This was discussed and agreed upon in Q4 on 2019 by the Falco community, and we are actively working on building out the infrastructure required in the Falco engine to enable this workflow.