✅ Deploy Preview for tetragon ready!

Name	Link
🔨 Latest commit	64dcd70
🔍 Latest deploy log	https://app.netlify.com/sites/tetragon/deploys/65bbb521c826c0000830d9fb
😎 Deploy Preview	https://deploy-preview-2050--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.

@mtardy @ycaoT I have taken a first step at the new tutorial. Please review and test the script, if possible. @ycaoT, does this address your needs from a user perspective? (The tutorial's weight should probably be increased from 1, so it does not appear before all the others.)

@christian-2 Thanks for the tutorial, this is definitely a good start. A bash script works, but I have some concerns for putting this into the real world, it may not be performant enough and may not able to deliver robust real time results. I am going to explore some middle layers like FluentBit or Vector.dev to further enrich the event outputs.

@yaot There is also always the other option that I had mentioned in #2030: an e.g. Go implementation of a gRPC client for carrying out the script's task with high performance. Admittedly I am not planning to work on this myself right now. But perhaps there is a way to "upvote" such a feature such that it may receive more overall attention. Maybe @mtardy can advise. In any case, good luck for your efforts.

@christian-2 Is that the right link? I don't see things related to the gRPC client.

@ycaoT My bad, there was a typo: it's #2030. I've mentioned gRPC there as well as in the description that accompanies the Bash script in this commit.

@mtardy Yes, I for one would be interested in participating in a blog post suitable for https://cilium.io/blog . It's an honor. I don't maintain a blog otherwise.

Could you help us with the next steps @xmulligan? I think it would mean opening a PR to add a new entry under https://github.com/cilium/cilium.io/tree/main/src/posts.

Yes, the correct way would be to create a PR like this one cilium/cilium.io#448

As an industry experience, especially for security and observability perspectives; I mentioned this in my original request too #2015. It will be very helpful if tetragon agent can provide a reliable way to output username, the userId does not provide much help in the real world. Falco already has this (if linking with /etc, they read from /etc/passwd, outputs like https://falco.org/docs/reference/rules/supported-fields/#field-class-user), I am sure tetragon can implement this too

@mtardy I am still planning to contribute that blog post (I should have all components ready), but in light of what I learned in #2228 about file descriptors I am also wondering whether a similar treatment could perhaps make sense for usernames in particular:

I.e. let Tetragon parse /etc/passwd (or whatever the Windows equivalent may be) when it starts up and let it put the association between uids and usernames into a dedicated eBPF map. Let it also monitor changes to /etc/passwd and update that map accordingly. Then let tracing policies use either uids or usernames as values for arguments that bear (a new) type uid.

UPDATE On reflection, it's perhaps too strong an assumption (even for Linux alone) that /etc/passwd always "owns" usernames. Clearly e.g. PAM allows for different configurations.

thanks @christian-2 . Totally agreed that: UPDATE On reflection, it's perhaps too strong an assumption (even for Linux alone) that /etc/passwd always "owns" usernames. Clearly e.g. PAM allows for different configurations.
But at least it's a good start, e.g: having a flag or mount to that file when the agent run, then it can use that to enrich the event outputs.

Again, I want to emphasize the intention of why, the uid is not going to help anything from security perspective, later turns to the compliance impact. We have to trace down events to the specific user (username) per both security and compliance requirements. Similar products, like Sysdig, Falco, Crowdstrike's agents are both able to deliver username in the outputs; but I dont know the implementation details.

I.e. let Tetragon parse /etc/passwd (or whatever the Windows equivalent may be) when it starts up and let it put the association between uids and usernames into a dedicated eBPF map. Let it also monitor changes to /etc/passwd and update that map accordingly. Then let tracing policies use either uids or usernames as values for arguments that bear (a new) type uid.

UPDATE On reflection, it's perhaps too strong an assumption (even for Linux alone) that /etc/passwd always "owns" usernames. Clearly e.g. PAM allows for different configurations.

So indeed, /etc/passwd is most of the time not enough, and I want to emphasize that this is mostly a userspace construction which limits a bit the comparison between file descriptors.

This is tricky, in the case of Tetragon we can't even use the same things used as in other tools (using the libc) because we want to build statically.

But this thing as been requested by multiple people and we see the interest.