Add customizable metadata fetching params

[zuc]

Signed-off-by: Michele Zuccala [email protected]

What type of PR is this?

/kind feature

Any specific area of the project related to this PR?

Not sure about the appropriate /area label here, could you please advise?

What this PR does / why we need it:

This PR adds support for customizable metadata fetching params that are going to be introduced with falcosecurity/libs#40.

Which issue(s) this PR fixes:

Special notes for your reviewer:

WIP because I'm planning to set the correct libs version and checksum once falcosecurity/libs#40 gets merged.

For now it's set to the feature branch name on https://github.com/falcosecurity/libs in order for this PR to be easily tested.

Does this PR introduce a user-facing change?:

new(userspace/falco): add customizable metadata fetching params

[poiana]

Welcome @zuc! It looks like this is your first PR to falcosecurity/falco 🎉

[zuc]

Note for the reviewer(s): I chose to keep m_metadata_download_max_mb expressed in megabytes for user-friendliness reasons, and to convert the value in bytes only when calling sinsp. Happy to discuss if you have a different point of view here!

[zuc]

Since falcosecurity/libs#40 got merged, this is now ready for review.
Also, driver version has been bumped to falcosecurity/libs@c415d57.

[leodido]

I believe that checking the config values (coming from the user) against limits (especially upper ones in this case) is necessary.

Example: a user configuring Falco to have max_mb equal to eg. 20000.

Since we know that this approach of fetching the container orchestrator metadata has an impact on memory (and Falco performances), I think it's sane to provide safe boundaries for them.

[zuc]

@leodido I added an upper boundary for the maximum download size, and a check to force frequency seconds to be higher than 0.

I don't think it would make much sense to cap the remaining params/boundaries given their meaning, but happy to discuss.

Dismissing this because your suggestion was accepted and the fix was committed more than two months ago

[leogr]

/approve

[poiana]

LGTM label has been added.

Git tree hash: 4eed899dc909ede675e884898a16c386c212cd58

[poiana]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: leogr, zuc

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 [leogr]

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