tracing-policies: support tags to categorize events

[tixxdz]

To categorize events we need a "tags" field that is a list of tags.

The Sigma Tags Specification is a good starting point: https://github.com/SigmaHQ/sigma-specification/blob/main/Tags_specification.md

We first define namespaces for events, and we start with the "observability" namespace.

observability: is the ability to collect and export data about the internal system state.

• "observability.filesystem": this event is about filesystem operations.
• "observability.privilege": this event is about the rights and permissions granted to a process or a user.
• "observability.process": this event is about an instance of a Linux program that is being executed.

tracing-policies: support tags to categorize events

[netlify[bot]]

✅ Deploy Preview for tetragon ready!

Name	Link
🔨 Latest commit	014c671b96d3e6e776b47f48284b9d4b905a4123
🔍 Latest deploy log	https://app.netlify.com/sites/tetragon/deploys/66055c628706120008523cba
😎 Deploy Preview	https://deploy-preview-2008--tetragon.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[tixxdz]

@jrfastab the namespace I added is "observability", doing "tracing" is an alternative, strictly speaking they are flexible.

But I prefer to have it "observability.tracing" for things bpf, kprobes, etc instead or even later "integrity.tracing" things that modify the kernel or memory... be more into users/tools that will consume Tetragon events and filter those events by tags, compared to doing the developer way of "tracing.filesystem" or "tracing.x" which will still stay a bit low level and hard to consume from a higher perspective.

[tixxdz]

Thanks that's a good addition! I just have some remarks on the Go code that could be simplified I think to be easier to read.

I'm not fan of the naming observability.privilege though I don't think very talkative while privilege_escalation or whatever is from MITRE or other standards is more explicit.

privilege_escalation seems what other tools are using, it is explicit, with the right filters we can surely use it, let's see what other think

[jrfastab]

overall I agree tag fields are useful way for user to get a field they can use for DB or whatever event monitoring system for filtering, categorizing, etc. But, I'm against embedding specific tags in Tetragon. Why do we care?

[jrfastab]

Could you also add an export filter for tags? I think that would be useful to enable/disable certain types of events posting to JSON logs.

[tixxdz]

overall I agree tag fields are useful way for user to get a field they can use for DB or whatever event monitoring system for filtering, categorizing, etc. But, I'm against embedding specific tags in Tetragon. Why do we care?

@jrfastab so we care:

1. As I'm pushing example https://github.com/cilium/tetragon/pull/1957 the privileges "raise" tracking, I want to tag all events with "observability.privilege" or "observability.privilege_escalation" if you prefer, but we surely do want to groupe those.
2. We do want to have some standards and avoid developers pushing their own tags spread here and there...
3. With default shipped policy, users can quickly get those events knowing the standard tags, they won't guess! (but we still don't ship default yet, for now only examples and policylibrary)
4. For tracing policies that do enforcement we certainly won't tag those with "observability", so I want to avoid shipping say enforcement policies that may surprise users or block their workload by accident! we can in Tetragon daemon say load only "observability" policies for now, and users can augment on that, just avoid the selinux story of killing users's workload ;-)

So yeh I'm anticipating a bit, ok I will remove the default namespaces for now, let's get this merged first, then I think we will shortly have to update the policylibrary with default tags... in other words tell our users look for those tags and you get the corresponding events. I let you sleep on it... :-)

Could you also add an export filter for tags? I think that would be useful to enable/disable certain types of events posting to JSON logs.

Ok will see how to add the export filter, fix and repush.

[jrfastab]

@tixxdz I'm all for groupings by tags and a default set of tags for different groups of observability and enforcement. I still don't follow why that needs to be embedded in the codebase. I'm happy with a dir in policylibrary for each taggroup though.

[tixxdz]

Thanks that's a good addition! I just have some remarks on the Go code that could be simplified I think to be easier to read.

I'm not fan of the naming observability.privilege though I don't think very talkative while privilege_escalation or whatever is from MITRE or other standards is more explicit.

Thanks @mtardy for the review, and I changed it to observability.privilege_escalation ;-)

[tixxdz]

@tixxdz I'm all for groupings by tags and a default set of tags for different groups of observability and enforcement. I still don't follow why that needs to be embedded in the codebase. I'm happy with a dir in policylibrary for each taggroup though.

So summary:

• Removed tags from the code, now they are only in documentation which I think having a default set of tags would help to keep things consistent.
• For export filter, I will open issue for it and we do it as a follow up.
• For enforcing Tags limit at kubebuilder it is done

[jrfastab]

Go ahead and merge after rebase to avoid future conflicts. Also I'll watch it today so when its green I can merge it as well if I see it.