Configure the fields exported by events produced for Runtime Threat Detection ( node-agent)

[henrikrexed]

Overview

Currently the event produced by the Runtime Threat Detection provides lots of details with the k8s metadata, the process details...And more.

Problem

When collecting the logs to a o11ybackend the default size of the strings are limited. Therefore the data is cropped .
All this details consumes bytes exchanged between cloud provider ..and will end up increasing the cloud cost.

Solution

Having an option to configure a list of fields that we would like to export from the event will allow users to decide on the type of details they would like to export. this is a feature that tetragon provides to control the size of the events produced : https://tetragon.io/docs/concepts/events/#export-filtering

Alternatives

Create a Otel collector pipeline that filter the data out.

[matthyx]

note to self, see if I can move it to node-agent project

[RohanKaran]

Hi @matthyx, I've looked into this. The event pipeline flows through ExporterBus to individual exporters and so adding an eventFieldFilter config (allow/deny list of field paths) to ExportersConfig, then applying JSON-based field stripping in ExporterBus.SendRuleAlert() before dispatching, similar to Tetragon's field_filters. Any other suggestions on the approach or should I start working on this?

[matthyx]

Looks reasonable to me.
cc @slashben if you could weight in?

[slashben]

Thanks @RohanKaran, direction looks good. One wrinkle: ExporterBus.SendRuleAlert dispatches typed types.RuleFailure structs, the JSON serialization happens inside each exporter (HTTP, stdout, syslog, etc.). So filtering at the bus before dispatch needs either struct mutation (with a clone) or pre-serialize/re-deserialize.

Cleaner: a helper that produces a filtered map[string]any from a RuleFailure + filter config, called by each JSON-emitting exporter just before its own marshal. Keeps filter logic in one place without changing the Exporter interface.

Couple of v1 choices to lock in before you start:

1. Allow-list vs deny-list. Suggest allow-list first (explicit, safer).
2. Scope to SendRuleAlert only, or also Malware/FIM. RuleAlert-only is fine for v1, matches the reporter's ask.
3. Global filter config (in ExportersConfig). Per-exporter can come later if needed.

Happy to review a PR once you have something.

[RohanKaran]

@slashben, thanks for the detailed explanation, went with per-exporter config on HTTPExporterConfig and JSON post-processing in sendHTTPRequest rather than a shared helper + global config, mainly because each exporter serialises differently (HTTP uses JSON paths, stdout uses log field names etc etc) so a shared map[string]any helper would need to know about both namespaces. post-processing on the already-marshalled bytes keeps it exporter-specific and avoids touching the Exporter interface.

that said, @matthyx mentioned a telemetry project that might rework this area, happy to rework this PR along the shared helper approach or whatever direction fits better with that, lmk if I should make changes or if this should wait

[matthyx]

wait, I'll put my PR next week