Historically, Falco container's information retrieval has always caused headaches to users; moreover, the current code does cause headaches to developers too.
While it's not always working fine, it also has some limitations:
Since the container info retrieval is done asynchronously at first clone/execve/fork event, we lose container metadata information for the very first syscall events generated by threads spawned in a new container
As previously stated, the code is also very hard to extend; there has been some previous attempts to improve it but for now that's what we got
Feature
Rewrite container info support as a plugin, and completely drop libsinsp internal implementation.
The plugin will leverage container engines SDKs to get notified when new containers are created/deleted; the container creation happens before the container is even started thus it should give us a time advantage and should avoid event without container metadata.
It will also be responsible of extracting all container and remaining k8s related filterchecks.
Main idea is to drop container manager from sinsp, and container_id from threadinfo.
The container_id will be added as a foreign key leveraging the libsinsp state table API by the plugin, that will take care of filling it.
Basically, sinsp without the plugin loaded will be completely unaware of containers.
All of the above should be done without breaking changes for the end users. In Falco 0.39 we added a container_engines configuration key: https://github.com/falcosecurity/falco/blob/master/falco.yaml#L1312; since it is in incubating state, we can drop it (since we will rely on the plugin init_config of course). That should be the only user-facing change.
I already have a private repo with the plugin source code i have been actively working on since mid october, and hope to be able to release it in time for Falco 0.40.0.
I also have an upstream libs branch where i am playing with the big cleanup: https://github.com/falcosecurity/libs/tree/cleanup/drop_container_manager.
I will drop the link to the plugin once i am satisfied with it and open source it :) Will share its architecture too.
Motivation
Historically, Falco container's information retrieval has always caused headaches to users; moreover, the current code does cause headaches to developers too. While it's not always working fine, it also has some limitations:
clone/execve/fork
event, we lose container metadata information for the very first syscall events generated by threads spawned in a new containerFeature
Rewrite container info support as a plugin, and completely drop libsinsp internal implementation. The plugin will leverage container engines SDKs to get notified when new containers are created/deleted; the container creation happens before the container is even started thus it should give us a time advantage and should avoid event without container metadata. It will also be responsible of extracting all
container
and remainingk8s
related filterchecks.Main idea is to drop container manager from sinsp, and container_id from threadinfo. The container_id will be added as a foreign key leveraging the libsinsp state table API by the plugin, that will take care of filling it. Basically, sinsp without the plugin loaded will be completely unaware of containers.
All of the above should be done without breaking changes for the end users. In Falco 0.39 we added a
container_engines
configuration key: https://github.com/falcosecurity/falco/blob/master/falco.yaml#L1312; since it is in incubating state, we can drop it (since we will rely on the plugininit_config
of course). That should be the only user-facing change.I already have a private repo with the plugin source code i have been actively working on since mid october, and hope to be able to release it in time for Falco 0.40.0. I also have an upstream libs branch where i am playing with the big cleanup: https://github.com/falcosecurity/libs/tree/cleanup/drop_container_manager.
I will drop the link to the plugin once i am satisfied with it and open source it :) Will share its architecture too.
Main issues:
Alternatives
No clear alternative.
Additional context
Listing related issues:
Next step would be to move
user/group
manager to a plugin too.