New transformer: `concat(<item1>, <item2>, ...)`

[leogr]

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:

1. In conditions for filtering.
2. 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 #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 #1981 for more context on the evaluated alternatives.

[therealbobo]

/assign

[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

[leogr]

/remove-lifecycle stale

[FedeDP]

/milestone 0.22.0

[incertum]

@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 ❤