[Proposal] Allow for custom outputs wrapper fields

[incertum]

Motivation

Falco currently sends alerts/logs with a predefined set of wrapper fields, some of which are configurable (such as tags, etc.).

For example:

{
  "hostname": "test-host",
  "priority": "Informational",
  "rule": "Test",
  "source": "syscall",
  "time": "2024-07-03T14:24:51.979324400Z",
  "output_fields": {}
}

Feature

For certain use cases, the end user may need to add custom static wrapper fields similar to hostname. We could support the following:

• Static key and value
• Static key and resolved value (such as an environment variable)

falco.yaml brainstorming: @LucaGuerra you always have great ideas on how to design the new falco.yaml UX, any ideas?

outputs_static_fields:
- key: my_static_outputs_field1
  value: "outputs_field1_string_value"
- key: my_static_outputs_field2
  value: ${CUSTOM_ENV_TO_BE_RESOLVED}

Dynamic custom fields that can change for each event or rule would not be supported. For such use cases, a custom plugin should be developed.

We have had similar requests in the past, but I can’t find the best issues to reference right now.

[incertum]

@falcosecurity/falco-maintainers

[leogr]

I'm in favor of something like that. Some time ago, I thought I would make a plugin for that, but I never did it. Now, I agree it makes sense to have this feature built-in to Falco for static fields.

Also, see that this may be somehow related to https://github.com/falcosecurity/falco/issues/3235. Maybe, we can design the two things at the same time

just my 2 cents

[leogr]

PS

I would consider force outputting these static fields under a specific class (e.g., labels.*) to avoid polluting the global space and avoid possible clashing.

[incertum]

I'm in favor of something like that. Some time ago, I thought I would make a plugin for that, but I never did it. Now, I agree it makes sense to have this feature built-in to Falco for static fields.

👍

Also, see that this may be somehow related to #3235. Maybe, we can design the two things at the same time

yes this would be great!

I would consider force outputting these static fields under a specific class (e.g., labels.*) to avoid polluting the global space and avoid possible clashing.

Edit: We can offer prefixes. For my use however, the name needs to be in an exact way, can't have a prefix.

[incertum]

/milestone 0.39.0

/assign