Allow Multiple Rules to Match Event

[ossie-git]

Motivation

As mentioned here - #1541 - only the first rule gets triggered and once Falco matches a rule, it stops processing other rules. This is meant as a performance improvement (I'm not sure by how much and it would be great if the actual speed improvements were documented somewhere) but it has the following serious cons:

• rule writers have to be very careful about rule ordering. In practice, this probably means that you can't have the default rules first unless you modify / disable rules that may possibly overshadow your own rule
• rule writers have to basically understand every rule that runs before their rule to make sure it doesn't match first
• if a rule writer places their rules first in a custom file (before the default rules file), they would have to copy over all the macros and lists they want to use to their new file
• you might end up disabling other useful rules in the fear that they overshadow your own rules
• when testing, you typically only test your own custom rule(s). This means that your rule(s) may work as intended in testing but not in production due to a default rule hiding it in production. And if your backend is configured to report only on rules with a given PRIORITY, you might end up with no alerts on either rule
• when adding new rules, you typically just add them to the end of the file instead of thinking where exactly in the rule order you have to insert them. Even the official rule set basically does this (for example, the k8s Audit All Events rule isn't the last rule in the file even though it would hide the rest of the rules after it). It isn't enabled by default but even then, it should be the last rule as it has the capability of hiding all remaining rules

It would therefore be great if this was configurable. I think very few rule authors will perform the necessary mental gymnastics needed for all of the above and it makes it more difficult for those who do want to add their own rules

Feature

an option in /etc/falco/falco.yaml to turn off the default behavior and allow all rules to be processed

Alternatives

Additional context

[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:

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. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[LucaGuerra]

/remove-lifecycle rotten

[jasondellaluce]

Now addressed by #2705 from @loresuso.

/close

[poiana]

@jasondellaluce: Closing this issue.

In response to this:

Now addressed by #2705 from @loresuso.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[jasondellaluce]

/milestone 0.36.0