update(cri): cri-dockerd support

[incertum]

What type of PR is this?

Uncomment one (or more) /kind <> lines:

/kind bug

/kind cleanup

/kind design

/kind documentation

/kind failing-test

/kind feature

Any specific area of the project related to this PR?

Uncomment one (or more) /area <> lines:

/area API-version

/area build

/area CI

/area driver-kmod

/area driver-bpf

/area driver-modern-bpf

/area libscap-engine-bpf

/area libscap-engine-gvisor

/area libscap-engine-kmod

/area libscap-engine-modern-bpf

/area libscap-engine-nodriver

/area libscap-engine-noop

/area libscap-engine-source-plugin

/area libscap-engine-savefile

/area libscap

/area libpman

/area libsinsp

/area tests

/area proposals

Does this PR require a change in the driver versions?

/version driver-API-version-major

/version driver-API-version-minor

/version driver-API-version-patch

/version driver-SCHEMA-version-major

/version driver-SCHEMA-version-minor

/version driver-SCHEMA-version-patch

What this PR does / why we need it:

Support cri-dockerd container runtime. Fixes falcosecurity/falco#3243.
To avoid looking up docker containers in this scenario from both the cri wrapper socket and the original docker socket configure the client like this: falcosecurity/falco#3243 (comment).

Falco PR falcosecurity/falco#3266.

Which issue(s) this PR fixes:

falcosecurity/falco#3243

Fixes #

Special notes for your reviewer:

Does this PR introduce a user-facing change?:

NONE

[poiana]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: incertum

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:

• OWNERS [incertum]

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

[FedeDP]

/milestone 0.18.0

[incertum]

I have the Falco PR up as well. This is ready for review, thanks.

[github-actions]

Perf diff from master - unit tests

     3.44%     +1.19%  [.] sinsp_parser::process_event
     4.16%     -1.18%  [.] sinsp_thread_manager::get_thread_ref
     4.67%     +0.99%  [.] sinsp_evt::get_type
     4.40%     +0.64%  [.] sinsp_thread_manager::find_thread
     5.32%     -0.59%  [.] next
    10.04%     +0.55%  [.] sinsp_parser::reset
     0.11%     +0.55%  [.] scap_event_has_large_payload
     0.43%     +0.54%  [.] sinsp_fdtable::find
     0.65%     -0.50%  [.] sinsp_evt::is_filtered_out
     1.61%     -0.43%  [.] sinsp_parser::event_cleanup

Perf diff from master - scap file

    19.61%     -6.80%  [.] sinsp_filter_check::extract_nocache
     3.30%     +5.91%  [.] sinsp_filter_check::rawval_to_string
     3.21%     +5.88%  [.] std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>
     6.46%     +5.87%  [.] sinsp_evt_formatter::tostring_withformat
    12.58%     -5.85%  [.] sinsp_thread_manager::get_thread_ref
     3.28%     +2.78%  [.] formatted_dump
     9.76%     -2.59%  [.] sinsp_filter_check::apply_transformers
     6.59%     -2.30%  [.] 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
     6.50%     -2.24%  [.] sinsp_threadinfo::~sinsp_threadinfo
     2.97%     +1.16%  [.] libsinsp::runc::match_one_container_id

Heap diff from master - unit tests

total runtime: 0.04s.
calls to allocation functions: -749 (-21400/s)
temporary memory allocations: -336 (-9600/s)
peak heap memory consumption: 0B
peak RSS (including heaptrack overhead): 0B
total memory leaked: 0B

Heap diff from master - scap file

total runtime: -0.011000s.
calls to allocation functions: 0 (0/s)
temporary memory allocations: 0 (0/s)
peak heap memory consumption: 0B
peak RSS (including heaptrack overhead): 0B
total memory leaked: 0B

[darryk10]

@incertum should we also add cri-dockerd in rules?
container_entrypoint macro should be one

[incertum]

@incertum should we also add cri-dockerd in rules? container_entrypoint macro should be one

Let's check, it may be just like regular docker (haven't checked the proc lineage) . I believe cri-dockerd is just a wrapper socket on top.