Add common plugins

[jfcoz]

What type of PR is this?

/kind cleanup
/kind feature

Any specific area of the project related to this PR?

/area build

What this PR does / why we need it:

Variant of #3746 , but with more plugins by default:

• json
• k8smeta
• k8saudit

they are the most used based on packages download count, and not specific to any cloud provider : https://github.com/orgs/falcosecurity/packages?sort_by=downloads_desc

Each pod should be able to start faster and without reaching this quota problem : falcosecurity/rules#331

Which issue(s) this PR fixes:

Does not fixes totally, but should improve falcosecurity/rules#331

Also this should allow to disable artifact-install and artifact-follow, and prevent supply chain attack.

And this reduce the image size from 212 to 136Mb.

Special notes for your reviewer:

I am quite new on this project, maybe it would be simpler to build theses plugins directly on the falco package which is installed in the Dockerfile.

Does this PR introduce a user-facing change?:

NONE

[poiana]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: jfcoz
Once this PR has been reviewed and has the lgtm label, please assign leogr for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• docker/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[leogr]

Hey @jfcoz

Thank you for this PR.

In the past, we already considered this. The decision was to move any plugin outside the container image. The container plugin is a special case because it's required to load the default ruleset of Falco. I'm always open to any options, but our current policy is: the fewer plugins we have in the image, the better.

Instead, moving rm -rf /usr/bin/falcoctl /etc/falcoctl/ in the previous RUN is an optimization that I like. If you make a new PR (or modify this PR) with the falcoctl change only, I would approve it.

[jfcoz]

@leogr , the move on the rm -rf /usr/bin/falcoctl /etc/falcoctl/ only is in this other PR: #3746

I need to use k8smeta, but would like to not download it at each pod start, how should I do instead ?

Maybe there could be some variants images, with k8saudit ? for each cloud provider with specific plugins ?

[leogr]

@leogr , the move on the rm -rf /usr/bin/falcoctl /etc/falcoctl/ only is in this other PR: #3746

👍 I had lost track of it. Now, I've approved it. Thanks!

I need to use k8smeta, but would like to not download it at each pod start, how should I do instead ?

You may want to create a custom container image that includes k8smeta. It should be easy to do; the only caveat is that you need to publish it in your own container registry. Note that you can just use ghcr.io for free and it's easy to configure.

Maybe there could be some variants images, with k8saudit ? for each cloud provider with specific plugins ?

Ideally yes. At a very early stage, when we introduced the plugin system, that was the initial plan. Unfortunately, as the number of plugins grew and the need to ship different kinds of Falco images for other purposes increased, it would have been hard to deal with all these image variants. So we eventually decided not to do that.

So, at the moment, you can do that yourself with only the cost of maintaining your custom image, as mentioned above.
But I'm open to discussing this together with other maintainers.

[ekoops]

I agree with what @leogr said regarding creating multiple specialized images. The number of combination is high, and the same would be for maintenance overheads. I suggest you to maintain your own Falco custom image with this trivial addition.

[leogr]

/hold