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

Jv runtime filtering collections feature DON'T REVIEW #1631

Closed
wants to merge 33 commits into from

Conversation

JoukoVirtanen
Copy link
Contributor

Description

A detailed explanation of the changes in your PR.

Feel free to remove this section if it is overkill for your PR, and the title of your PR is sufficiently descriptive.

Checklist

  • Investigated and inspected CI test results
  • Updated documentation accordingly

Automated testing

  • Added unit tests
  • Added integration tests
  • Added regression tests

If any of these don't apply, please comment below.

Testing Performed

TODO(replace-me)
Use this space to explain how you tested your PR, or, if you didn't test it, why you did not do so. (Valid reasons include "CI is sufficient" or "No testable changes")
In addition to reviewing your code, reviewers must also review your testing instructions, and make sure they are sufficient.

For more details, ref the Confluence page about this section.

Molter73 and others added 30 commits March 26, 2024 19:20
This commit reenables Falco's full build in order to enable us using the
container engines to extract k8s metadata from container labels. A
feature flag has been added in order to maintain the current behaviour
of using our custom engine that just grabs container ID from cgroups or
default to using Falco's engines that also capture metadata by querying
runtimes.

In order to simplify and (somewhat) abstract extraction of fields, a new
K8s class has been created. Unfortunately, due to how Falco works, we
still need to pass in the inspector to the constructor and the events
need to be forwarded to the getters for the metadata.

By default only CRI, CRI-O and containerd engines are used (all 3 of
them share the same API), but a couple configuration flags have been
added to enable using docker and podman in case we need them at some
point in time.
as filter object for runtime config
…d some refactoring to use more functions and less nesting
…nit test before embedded collections are added
Co-authored-by: Mauro Ezequiel Moltrasio <[email protected]>
Moved packages from the suites directory to a pkg directory, this should
make it clearer what things are helper packages and what are actual
tests.
Refactored executor and collector_manager packages out of the common
package.
Implemented a bare-bones k8s based executor (still needs testing).
The added integration tests relay on KinD being available on the running
system.
- Renamed collector_manager package to collector.
- Renamed multiple objects in the collector package to shorter names.
- Added helper functions to the collector package for getting log paths.
- Created a general ContainerFilter object that can be used for multiple
  operations in the executor package.
@JoukoVirtanen JoukoVirtanen changed the title Jv runtime filtering collections feature Jv runtime filtering collections feature DON'T REVIEW Apr 11, 2024
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