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

[poiana]

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

[leogr]

/remove-lifecycle stale

[leogr]

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.

@FedeDP will your container plugin implementation go in this direction? Or is it still TBD? 🤔

[FedeDP]

Still TBD!

[poiana]

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

[leogr]

re: falcosecurity/falco#3403
@FedeDP will the new implementation change the legacy behavior w.r.t. container.id and container.name?

[FedeDP]

No we decided to avoid any breaking change in that regard.