ka.useragent field

[fntlnz]

What type of PR is this?

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

/kind feature
/kind cleanup

If contributing rules or changes to rules, please make sure to also uncomment one of the following line:
NONE

Any specific area of the project related to this PR?

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

/area engine

What this PR does / why we need it:

• Adds the ka.useragent field as alias of jevt.value[/userAgent]
• Doing this also required another commit to do the necessary formatting according to the new .clang-format

Which issue(s) this PR fixes:

Fixes #698

Special notes for your reviewer:

Does this PR introduce a user-facing change?:

fields: kubernetes audit ka.useragent alias

[fntlnz]

To test this, this rule can be used:

- rule: Only allow hyperkube as useragent
  desc: Test doing an useragent check for k8s audit
  condition: ka.useragent != "hyperkube"
  priority: ERROR
  output: "unexpected client useragent: useragent=%ka.useragent " 
  source: k8s_audit

Here is a detection example:

Events detected: 434
Rule counts by severity:
   ERROR: 434
Triggered rules by rule name:
   Only allow hyperkube as useragent: 434
Syscall event drop monitoring:
   - event drop detected: 44 occurrences
   - num times actions taken: 11

[fntlnz]

/assign @leodido

[poiana]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: leodido

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

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

[poiana]

LGTM label has been added.

Git tree hash: 8dc8e963bf40037050801d27534d2dce0a4dfbfd

[mstemm]

When you update the checksum, that almost always means new fields were added to either sysdig (for syscall events) or falco (for k8s audit events). When that happens, you should also bump the FALCO_ENGINE_VERSION define on line 22. That allows us to know the times at which the engine was upgraded to have new fields. When you actually use those fields, you should update the rules file that uses them to have a - required_engine_version: NNN where NNN is the current value of FALCO_ENGINE_VERSION.

[fntlnz]

good to know, is this documented anywhere or should we do it? @mstemm

[mstemm]

From a user perspective, there are some notes at https://falco.org/docs/rules/#versioning. Not much for developer specific notes, though.

[mstemm]

In the future, I think it would be a good idea to separate whitespace/formatting changes from other changes. It's hard to tell which changes are simply syntax and which change behavior.

(It is a separate commit, which is very handy, but I think even as a separate PR is better, as it's easier to identify from the PR name).

[fntlnz]

@mstemm We did the changes in two separate commits, however I agree that doing in two different PRs would've been even better!