Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kernel event tracing owned and maintained by Falco #976

Open
kris-nova opened this issue Dec 16, 2019 · 3 comments
Open

Kernel event tracing owned and maintained by Falco #976

kris-nova opened this issue Dec 16, 2019 · 3 comments
Labels
Milestone

Comments

@kris-nova
Copy link
Member

@kris-nova kris-nova commented Dec 16, 2019

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.

  1. Kernel Tracing (using libscap and libsinsp and either a kernel module or eBPF probe
  2. Kubernetes meta information (Basic information from the Kubernetes API server)
  3. Kubernetes audit logs
  4. Container metainformation from container runtime (EX: Docker socket)

The 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 sysdig CLI 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.

Screenshot from 2019-12-16 14-46-03

@kris-nova kris-nova added this to the 1.0.0 milestone Dec 16, 2019
@kris-nova

This comment has been minimized.

Copy link
Member Author

@kris-nova kris-nova commented Dec 16, 2019

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

@kris-nova kris-nova changed the title Kernel Event Tracing in Falco Kernel event tracing owned and maintained by Falco Dec 16, 2019
@kris-nova

This comment has been minimized.

Copy link
Member Author

@kris-nova kris-nova commented Dec 20, 2019

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.

@KnoxAnderson

This comment has been minimized.

Copy link

@KnoxAnderson KnoxAnderson commented Dec 20, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.