Kernel event tracing owned and maintained by Falco

[krisnova]

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.

[krisnova]

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

[krisnova]

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 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.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[nathan-b]

I love the idea of separate input data streams for falco. I appreciate the fact that I get to choose what inputs I care about and I don't get bogged down processing events that don't matter to me. It's also great to decouple these streams. Fully in favor of this project.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[fntlnz]

Stalebot please keep!

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. Issues labeled "cncf", "roadmap" and "help wanted" will not be automatically closed. Please refer to a maintainer to get such label added if you think this should be kept open.

[poiana]

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

[poiana]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh with /remove-lifecycle rotten.

Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle rotten

[poiana]

Rotten issues close after 30d of inactivity.

Reopen the issue with /reopen.

Mark the issue as fresh with /remove-lifecycle rotten.

Provide feedback via https://github.com/falcosecurity/community. /close

[poiana]

@poiana: Closing this issue.

In response to [this](https://github.com/falcosecurity/falco/issues/976#issuecomment-768572158): >Rotten issues close after 30d of inactivity. > >Reopen the issue with `/reopen`. > >Mark the issue as fresh with `/remove-lifecycle rotten`. > >Provide feedback via https://github.com/falcosecurity/community. >/close Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.