-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Duplicated entries across various falco
rules files
#151
Comments
Issues go stale after 90d of inactivity. Mark the issue as fresh with Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with Provide feedback via https://github.com/falcosecurity/community. /lifecycle stale |
/remove-lifecycle stale |
/assign |
Issues go stale after 90d of inactivity. Mark the issue as fresh with Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with Provide feedback via https://github.com/falcosecurity/community. /lifecycle stale |
/remove-lifecycle stale still relevant |
cc @falcosecurity/falco-maintainers |
It makes the most sense. Worth it the transition LOE I would say. Not having any better ideas. Right now for example I dedup the macros and lists in a custom patch script, but there are adopters who wish to not needing to use a custom patch script. |
falco
rules filesfalco
rules files
Just as a reference. The new idiomatic way to express "this list is defined somewhere else - ie, in another file" would now be: - list: foo
items: []
override:
- items: append |
Issues go stale after 90d of inactivity. Mark the issue as fresh with Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with Provide feedback via https://github.com/falcosecurity/community. /lifecycle stale |
/remove-lifecycle stale |
@leogr: Please ensure the request meets the requirements listed here. If this request no longer meets these requirements, the label can be removed In response to this:
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-sigs/prow repository. |
Motivation
See #149 (comment)
The common use case is when a list or a macro is first defined in the stable rules file, but it is also needed (as-is or extended) by other rules files.
Feature
Likely, the simplest way to address this is to define a standard way to express list and macro dependencies requirements.
This would force the user to load another rules file with the missing list or macro definition, without the need of duplicating the whole list or macro.
However, the design of this feature is still TBD
@falcosecurity/core-maintainers
Alternatives
Keep duplicate entries, as it is now. In this way, duplicated items are just silently overwritten. The only con is that the loading order affects the end results when the duplicate item is not identical (for example, if it has been modified in one file but not in the other).
Additional context
See #149 (comment)
The text was updated successfully, but these errors were encountered: