You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We often have new falco rules that depend on a new event type or filtercheck. If someone is simply using the released version of falco, the rules change will always come alongside a sysdig version that supports the event type/etc in the rule.
However, some users want to pick up the latest rules changes independent from a given falco release. In this case, their falco + sysdig version might not necessarily have the new event type/filtercheck that the rule uses.
It would be nice if the rules format allowed for loading a given rule only if a given event type/filtercheck/other capability were supported by the underlying falco + sysdig software. This would allow for some flexibility without having to deal with full versioning between sysdig and the rules file.
If this ends up not being feasible, we could always add a best-effort rules loading method that simply skipped individual rules that contained condition or output fields that can't be parsed. This isn't a great solution, however, as it could mask unintended problems such as typos, etc. in the condition/output field.
The text was updated successfully, but these errors were encountered:
We often have new falco rules that depend on a new event type or filtercheck. If someone is simply using the released version of falco, the rules change will always come alongside a sysdig version that supports the event type/etc in the rule.
However, some users want to pick up the latest rules changes independent from a given falco release. In this case, their falco + sysdig version might not necessarily have the new event type/filtercheck that the rule uses.
It would be nice if the rules format allowed for loading a given rule only if a given event type/filtercheck/other capability were supported by the underlying falco + sysdig software. This would allow for some flexibility without having to deal with full versioning between sysdig and the rules file.
If this ends up not being feasible, we could always add a best-effort rules loading method that simply skipped individual rules that contained
condition
oroutput
fields that can't be parsed. This isn't a great solution, however, as it could mask unintended problems such as typos, etc. in the condition/output field.The text was updated successfully, but these errors were encountered: