Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

new(userspace): added new addOutput json entry for plugin get_field() API #2116

Merged
merged 3 commits into from
Oct 21, 2024

Conversation

FedeDP
Copy link
Contributor

@FedeDP FedeDP commented Oct 16, 2024

What type of PR is this?

/kind feature

Any specific area of the project related to this PR?

/area libsinsp

Does this PR require a change in the driver versions?

What this PR does / why we need it:

The new field suggests to the agent that some fields should be enforced to all compatible sources output by default.
It is up to the agent to implement the logic to actually use these suggested fields.
PR contains also updated tests.

For example, k8smeta plugin could expose eg: k8smeta.pod.name and k8smeta.pod.uid as addOutput fields; this way for syscall event source (see get_extract_event_sources: https://github.com/falcosecurity/plugins/blob/main/plugins/k8smeta/src/plugin.h#L154) those fields will always be appended to the output with no further intervention.

Idea is then to have a for-plugin config option in Falco to disable this behavior by default.

Basically, this feat would allow us to avoid leaking plugin-related knowledge about which output should be appended by default, up to Falco. For example, we could drop the pk Falco option that is used by charts when enabling the k8smeta collector: https://github.com/falcosecurity/charts/blob/master/charts/falco/templates/pod-template.tpl#L78

Long term goal is to drop all print related Falco CLI options: https://github.com/falcosecurity/falco/blob/master/userspace/falco/app/actions/init_falco_engine.cpp#L55
when:

  • container support becomes a plugin
  • gvisor becomes a plugin

Which issue(s) this PR fixes:

Fixes #

Special notes for your reviewer:

Does this PR introduce a user-facing change?:

new(userspace): added new `addOutput` json entry for plugin `get_field()` API

…d()` API.

It suggests to Falco that some fields should be enforced to
all compatible sources output.

Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
@FedeDP
Copy link
Contributor Author

FedeDP commented Oct 16, 2024

/milestone 0.19.0
/cc @jasondellaluce @mrgian

@poiana poiana added this to the 0.19.0 milestone Oct 16, 2024
@poiana
Copy link
Contributor

poiana commented Oct 16, 2024

@FedeDP: GitHub didn't allow me to request PR reviews from the following users: mrgian.

Note that only falcosecurity members and repo collaborators can review this PR, and authors cannot review their own PRs.

In response to this:

/milestone 0.19.0
/cc @jasondellaluce @mrgian

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

@poiana poiana added the size/M label Oct 16, 2024
@poiana
Copy link
Contributor

poiana commented Oct 16, 2024

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: FedeDP

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Copy link

github-actions bot commented Oct 16, 2024

Perf diff from master - unit tests

     8.45%     -1.40%  [.] sinsp::next
     2.05%     +1.23%  [.] sinsp_thread_manager::find_thread
     4.34%     +1.10%  [.] next
    10.25%     +0.96%  [.] sinsp_parser::reset
     0.89%     -0.61%  [.] sinsp_fdtable::sinsp_fdtable
     1.72%     -0.52%  [.] libsinsp::sinsp_suppress::process_event
     0.22%     +0.45%  [.] sinsp_fdtable::find
     1.72%     +0.44%  [.] std::_Hashtable<long, std::pair<long const, std::shared_ptr<sinsp_threadinfo> >, std::allocator<std::pair<long const, std::shared_ptr<sinsp_threadinfo> > >, std::__detail::_Select1st, std::equal_to<long>, std::hash<long>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<false, false, true> >::_M_find_before_node
     5.62%     -0.42%  [.] sinsp_parser::process_event
     2.67%     +0.41%  [.] sinsp_thread_manager::get_thread_ref

Heap diff from master - unit tests

peak heap memory consumption: 0B
peak RSS (including heaptrack overhead): 0B
total memory leaked: 0B

Heap diff from master - scap file

peak heap memory consumption: 0B
peak RSS (including heaptrack overhead): 0B
total memory leaked: 0B

Benchmarks diff from master

Comparing gbench_data.json to /root/actions-runner/_work/libs/libs/build/gbench_data.json
Benchmark                                                         Time             CPU      Time Old      Time New       CPU Old       CPU New
----------------------------------------------------------------------------------------------------------------------------------------------
BM_sinsp_split_mean                                            -0.0304         -0.0305           156           151           156           151
BM_sinsp_split_median                                          -0.0277         -0.0278           156           151           156           151
BM_sinsp_split_stddev                                          +0.2814         +0.2824             1             1             1             1
BM_sinsp_split_cv                                              +0.3216         +0.3227             0             0             0             0
BM_sinsp_concatenate_paths_relative_path_mean                  -0.0074         -0.0075            62            61            62            61
BM_sinsp_concatenate_paths_relative_path_median                +0.0027         +0.0026            62            62            62            62
BM_sinsp_concatenate_paths_relative_path_stddev                +1.1228         +1.1195             1             2             1             2
BM_sinsp_concatenate_paths_relative_path_cv                    +1.1387         +1.1355             0             0             0             0
BM_sinsp_concatenate_paths_empty_path_mean                     +0.0541         +0.0540            24            25            24            25
BM_sinsp_concatenate_paths_empty_path_median                   +0.0482         +0.0481            24            25            24            25
BM_sinsp_concatenate_paths_empty_path_stddev                   +1.6388         +1.6342             0             0             0             0
BM_sinsp_concatenate_paths_empty_path_cv                       +1.5033         +1.4991             0             0             0             0
BM_sinsp_concatenate_paths_absolute_path_mean                  +0.0006         +0.0005            62            62            62            62
BM_sinsp_concatenate_paths_absolute_path_median                +0.0100         +0.0099            62            63            62            63
BM_sinsp_concatenate_paths_absolute_path_stddev                +5.5585         +5.5519             0             1             0             1
BM_sinsp_concatenate_paths_absolute_path_cv                    +5.5543         +5.5484             0             0             0             0
BM_sinsp_split_container_image_mean                            +0.0100         +0.0099           390           394           390           394
BM_sinsp_split_container_image_median                          +0.0101         +0.0100           390           394           390           394
BM_sinsp_split_container_image_stddev                          -0.0482         -0.0477             2             2             2             2
BM_sinsp_split_container_image_cv                              -0.0576         -0.0571             0             0             0             0

Copy link

codecov bot commented Oct 16, 2024

Codecov Report

Attention: Patch coverage is 76.47059% with 4 lines in your changes missing coverage. Please review.

Project coverage is 74.46%. Comparing base (c082ec3) to head (09995e3).
Report is 18 commits behind head on master.

Files with missing lines Patch % Lines
userspace/libsinsp/plugin.cpp 71.42% 2 Missing ⚠️
userspace/libsinsp/test/plugins.ut.cpp 80.00% 2 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master    #2116      +/-   ##
==========================================
+ Coverage   73.69%   74.46%   +0.76%     
==========================================
  Files         253      253              
  Lines       31916    33069    +1153     
  Branches     5608     5682      +74     
==========================================
+ Hits        23521    24624    +1103     
- Misses       8364     8423      +59     
+ Partials       31       22       -9     
Flag Coverage Δ
libsinsp 74.46% <76.47%> (+0.76%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Contributor

@jasondellaluce jasondellaluce left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks amazing Fede!

Design question/suggestion: why don't we add a new filtercheck_field_flags flag (e.g. EPF_FORMAT_SUGGESTED or something like that) and make this a property of fields in general?

The plugin API will keep defining this property in the way you proposed, but I feel like having a standard mechanism would be more beneficial rather then having an extra getter or code path for plugins only. That way, consumers like Falco will just reason about fields/filters list compared to being aware of plugins and their specifics

userspace/libsinsp/plugin.h Outdated Show resolved Hide resolved
@FedeDP
Copy link
Contributor Author

FedeDP commented Oct 21, 2024

Design question/suggestion: why don't we add a new filtercheck_field_flags flag (e.g. EPF_FORMAT_SUGGESTED or something like that) and make this a property of fields in general?

I quite like it indeed!
I just didn't think about that one (little experience with filterchecks :D ), thanks, i am going to introduce it!

FedeDP and others added 2 commits October 21, 2024 14:57
…ld flag.

Signed-off-by: Federico Di Pierro <nierro92@gmail.com>

Co-authored-by: Jason Dellaluce <jasondellaluce@gmail.com>
…ormats` API.

Signed-off-by: Federico Di Pierro <nierro92@gmail.com>

Co-authored-by: Jason Dellaluce <jasondellaluce@gmail.com>
@poiana poiana merged commit bf7828c into master Oct 21, 2024
49 checks passed
@poiana poiana deleted the new/plugin_api_addoutput branch October 21, 2024 14:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants