falcosecurity
Semantic of `container.id` and `container.name`
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: :point_down:
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: :point_down:
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:
- Leave
container.nameunset (like othercontainer.*fields) and continue usingcontainer.id=host. - Leave both
container.idandcontainer.nameunset. This would makenot container.id existswork 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 <NA> issue) is orthogonal to this issue. Still, it should be taken into consideration
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
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
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 forhostinstead.
@FedeDP will your container plugin implementation go in this direction? Or is it still TBD? :thinking:
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
re: https://github.com/falcosecurity/falco/issues/3403
@FedeDP will the new implementation change the legacy behavior w.r.t. container.id and container.name?
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle rotten
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
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