Closed jasondellaluce closed 1 year ago
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
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten
.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close
.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle rotten
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen
.
Mark the issue as fresh with /remove-lifecycle rotten
.
Provide feedback via https://github.com/falcosecurity/community. /close
@poiana: Closing this issue.
Motivation
Plugins can support the field extraction capability that allow them to add new fields in the engine that can be used in filtering conditions and formatters, such as Falco rules. For example, this is used by the
json
plugin to support new fields such asjson.value[...]
.However, the libraries currently do not allow plugins to extract new fields from syscall events. Plugins can extract fields just from event sources implemented by other plugins. As a reference, it is legit for the
json
plugin to extract values from both thek8saudit
andaws_cloudtrail
event sources, but not for syscalls (the framework blocks the plugin from receiving those events entirely). This is mostly caused by technical reasons, the first one being the fact that inspecting syscall events would also imply inspecting the libsinsp internal state, for which we don't have a clean interface yet.Feature
Allow plugins to receive syscall events for field extraction purposes, and support a clean interface for accessing the event data and the related libsinsp state.
Additional context
Linked discussions:
Linked issues: