Describe the bug
The hostname value in Falco logs can be overridden but can not be omitted, which creates conflicts with logging providers like Datadog. Currently, Falco uses the node name (from FALCO_HOSTNAME environment variable) as the host/hostname attribute value. This is problematic because Datadog reserves this field and uses <node name>-<cluster name> as an internal ID for infrastructure/log correlation.
How to reproduce it
- Deploy the latest version of Falco using the Helm chart (v4.12.0)
- Observe the JSON output logs, which will contain a hostname entry like:
{
"hostname": "falco-mnv9v",
"output": "...",
"priority": "Notice",
"rule": "...",
"source": "...",
"tags": [...],
"time": "2023-05-03T12:20:03.418079886Z",
"output_fields": {...}
}Expected behaviour
The system should provide an option to completely omit the hostname field from logs to avoid conflicts with logging providers
Environment
Additional context
A similar issue was reported in #2530 however the previously suggested solution (overriding hostname value viaFALCO_HOSTNAME) isn't adequate for our use case. The chart parameter suggested here would provide the solution we are looking for.
If the Falco team is open to it, we would be happy to have a go at implementing a fix.
Thanks!
Describe the bug
The hostname value in Falco logs can be overridden but can not be omitted, which creates conflicts with logging providers like Datadog. Currently, Falco uses the node name (from FALCO_HOSTNAME environment variable) as the host/hostname attribute value. This is problematic because Datadog reserves this field and uses
<node name>-<cluster name>as an internal ID for infrastructure/log correlation.How to reproduce it
{ "hostname": "falco-mnv9v", "output": "...", "priority": "Notice", "rule": "...", "source": "...", "tags": [...], "time": "2023-05-03T12:20:03.418079886Z", "output_fields": {...} }Expected behaviour
The system should provide an option to completely omit the hostname field from logs to avoid conflicts with logging providers
Environment
Falco version: 0.38.1
Cloud provider or hardware configuration: Azure Kubernetes Service
OS: Debian Bookworm
Additional context
A similar issue was reported in #2530 however the previously suggested solution (overriding hostname value via
FALCO_HOSTNAME) isn't adequate for our use case. The chart parameter suggested here would provide the solution we are looking for.If the Falco team is open to it, we would be happy to have a go at implementing a fix.
Thanks!