libs
libs copied to clipboard
falcosecurity
New transformer: `concat(<item1>, <item2>, ...)`
Motivation
Please look at this comment for context.
The concat(<item1>, <item2>, ...) transformer concatenates items (either a field or a literal string) given as arguments and returns a new string.
Its output can be utilized in two primary ways:
- In conditions for filtering.
- In the
output:field of Falco's rule.
One significant use case is concat(fd.rip, ":", fd.rport) in ("8.8.8.8:53","4.4.4.4:53") as reported by https://github.com/falcosecurity/libs/issues/1981
Feature
Implement the concat(<item1>, <item2>, ...) as described above.
The transformer should return a concatenated string.
Note: Implementing this transformer requires extending the current syntax to allow a variable number of arguments to be accepted by a transformer.
Alternatives
Please look at https://github.com/falcosecurity/libs/issues/1981 for more context on the evaluated alternatives.
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
@therealbobo shared his staging commits with me, and I reviewed them yesterday. Since I am gradually off-boarding from the project, I won’t be able to assist further, but I wanted to share a few observations. There appears to be a mix-up between the join( and concat( functionality and layout, which may indicate a need to re-evaluate the two newly planned transformers.
Effectively, this is the feature @therealbobo started working, assuming it was the join( transformer. However, the version he worked on is as follows:
join("->", (proc.name, evt.arg.path))
The question is: do we want to stick to the final version discussed above (concat(<item1>, <item2>, ...)), or are there technical reasons to favor a single delimiter and wrap all field names in parentheses, as @therealbobo did above? Lastly, should we allow free-form delimiters, or should we restrict them to a predefined set? Alternatively, should we require them to be wrapped in a specific lex helper string similar to val() — for instance, using lit()?
There are several possible approaches, and it may be worth discussing further before someone opens a PR.
Various options:
concat(fd.rip, ":", fd.rport)concat(fd.rip, lit(":"), fd.rport)concat(":", fd.rip, fd.rport)concat(":", (fd.rip, fd.rport))- TBA
Also thanks @therealbobo for already putting in so much effort into this feature ❤
I don't have a strong preference as to how this is implemented. The current approach looks sufficient to meet the requirements for ip:port. Great job @therealbobo Thanks!
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
@leogr: This request has been marked as needing help from a contributor.
Please ensure the request meets the requirements listed here.
If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.
In response to this:
/remove-lifecycle stale /help
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.