Add an ID field to the detection rule to help trace it back to the TracingPolicy

[alex-ilgayev]

At the moment, all tracing events received from tetragon don't have any context to the "TracingPolicy" defined that rule in the first place. For kprobe events for example, the best chance to correlate it is by using the function_name field, which may have several policy hooks for that specific function, so it isn't sufficient.

A sample usage could be to trace several kinds of write operations to files, that each belongs to a different kind of policy, and analyze the output properly depending on the source policy. Many more use cases could be thought of.

That ID field could be the metadata.name for tracing policy which is usually defined:

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: "fd_install"
...

[willfindlay]

Heavy :+1: from me. One question though: what do we think should happen if more than one tracing policy could have been responsible for a single event? Would we just take the first one and use it as the ID here?

[jrfastab]

I would use whatever one actually did the post_event action. So if you have a fd_install follow and then a open() hook I would add whatever ID is triggered by that open(). This way if you have follow and then multiple hooks on that file you get unique ids for all of them.