Indicate the modern ebpf probe as the preferred deployment method for Falco

[Andreagit97]

/area documentation

What would you like to be added:

I'm noticing that the modern ebpf probe is still not widely known among users. There are cases in which using the modern probe could solve issues without any burden, but it seems users are not aware of its existence (e.g. #1135 (comment)). So I propose to put the modern ebpf engine as the preferred installation method all around the documentation so: helm chart, docker, deb/rmp, tag.gz.

Always in this direction, it could be useful to have a step-by-step tutorial on how to react to a Falco failure and change the running driver setting the modern bpf. This could be a simple example:

1. try to install falco with helm chart + legacy ebpf
2. it doesn't work out of the box, because the pre-built driver is missing
3. show how to check and read the logs to understand what is happening (why Falco is crashing)
4. change the driver in the helm chart and using the modern-ebpf
5. show that all works as expected with a simple rule triggered

This sort of tutorial could help in cases like this: falcosecurity/falco#2982

More in general having a dedicated page in the doc where we explain what to do when users face certain errors would be amazing, for example it could avoid issues like this: falcosecurity/falco#2989

TL:DR;

1. Set the modern ebpf probe as the default installation method in the doc
2. Have a sort of step-by-step tutorial on how to migrate from old drivers to the modern bpf, explaining why the modern bpf works
3. Have a general documentation page with the most frequent error messages and what to do to recover, we can use this issue as an initial reference [UMBRELLA] Errors at Falco start-up related to Falco's kernel driver {kmod, bpf, modern_bpf} falco#2873

[incertum]

+1

Taking it one step further, make modern_ebpf the default driver as it's a significant overhead for us maintainers to assist adopters in debugging when Falco is not starting up.

I think by now for the most part folks getting started with Falco are likely to try Falco on newer kernels. Folks who still need to support older kernels are probably more familiar with kernel dev etc and should be able to understand a clear error message stating that you need to use either the ebpf or kmod driver. More thoughts? We can move this to a dedicated discussion.

[incertum]

Also @Andreagit97 in fact we need more dedicated "debugging" guides:

Help (located under Install and Operate)

• Help, Falco is Dropping Events (-> Melissa as suggested by @FedeDP in a recent slack thread, this would be a combination of expanding https://falco.org/docs/install-operate/production-performance/ where I was thinking of explaining metrics better and index all supported metrics fields)
• Help, Missing Container Images
• Help, Missing or Empty Fields
• Help, Falco is Not Starting (you suggested guide)

How would you all like such an outline?

[Andreagit97]

Taking it one step further, make modern_ebpf the default driver as it's a significant overhead for us maintainers to assist adopters in debugging when Falco is not starting up.

I think by now for the most part folks getting started with Falco are likely to try Falco on newer kernels. Folks who still need to support older kernels are probably more familiar with kernel dev etc and should be able to understand a clear error message stating that you need to use either the ebpf or kmod driver. More thoughts? We can move this to a dedicated discussion.

it makes sense to me! it would be great to have some stats on how many users are using the modern ebpf probe today, just to have an idea of the possible impact, but I'm not sure how to obtain this information, maybe we can try with a poll on the Falco channel...WDYT?

Also @Andreagit97 in fact we need more dedicated "debugging" guides:

I Like it very much!! Fully on board!

[incertum]

Awesome, yes a poll in the channel would be great!

Perhaps at first we can keep kmod in the falco.yaml, but at least we enable Falco by default in the helm chart.

Another possibility could be to fallback to kmod (the old default) when modern_ebpf is not supported by the system? kmod seems the best fallback choice as it has the widest support range. Of course ebpf could be the last attempt if conditions for kmod are not met, e.g. DKMS and such.

[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

[Andreagit97]

/remove-lifecycle stale

[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

[Andreagit97]

The first point should be in place!

/remove-lifecycle stale

[incertum]

wohoo given it is a tremendous overhead for all maintainers.

[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

[Andreagit97]

/remove-lifecycle stale