Semantic of container.id and container.name

[leogr]

Motivation

Historically, when a syscall event occurs outside a container, the container.id field is set to host. Our ruleset has consistently followed this pattern: 👇

https://github.com/falcosecurity/rules/issues/new?permalink=https%3A%2F%2Fgithub.com%2Ffalcosecurity%2Frules%2Fblob%2Fb6ad37371923b28d4db399cf11bd4817f923c286%2Frules%2Ffalco_rules.yaml%23L226-L227

This behavior is also documented in the official documentation.

Although this design decision is opinionated, it works since a container ID cannot be host.

The container.name field currently follows the same pattern: 👇
https://github.com/incertum/libs/blame/master/userspace/libsinsp/filterchecks.cpp#L6232-L6236

However, using container.name = host is unsafe because a container could be named host.

Overall, the current approach could lead to confusion or errors.

Feature

To resolve this issue for non-container cases, we propose two backward-incompatible solutions:

1. Leave container.name unset (like other container.* fields) and continue using container.id=host.
2. Leave both container.id and container.name unset. This would make not container.id exists work correctly (assuming the empty value problem will also be fixed).

Alternatives

Doing nothing is not an option, as container.name = host could be misleading.

Additional context

This change would be a major breaking change and should be targeted for Falco 1.0.

Also note the empty value problem (a.k.a. the issue) is orthogonal to this issue. Still, it should be taken into consideration

[FedeDP]

Thanks for reporting this one Leo!
Going the full breaking change route, i'd say 2. is the best solution; i love not container.id exists, feels so much better than looking for host instead.

Also, cc @incertum