falco
falco copied to clipboard
falcosecurity
cleanup(docker): avoid linking /lib/modules to /host/lib/modules at docker image creation time
What type of PR is this?
/kind cleanup
Any specific area of the project related to this PR?
What this PR does / why we need it:
Avoid linking /lib/modules to /host/lib/modules at docker image creation time. Instead, do it in docker-entrypoint scripts, so that even users using different HOST_ROOT than "/host", will still have a working image.
Moreover, if HOST_ROOT is set, but "$HOST_ROOT/proc" is not present, soft link "/proc" to "HOST_ROOT/proc", to allow Falco to run. Otherwise, scap_procs would exit with error and kill the istance.
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?:
cleanup: allow users that use a different HOST_ROOT to still have a working falco-driver-loader driver compilation.
[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: FedeDP
The full list of commands accepted by this bot can be found here.
The pull request process is described here
- ~~docker/OWNERS~~ [FedeDP]
Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment
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
Since /lib/modules is only required to build the driver, why not put this logic inside falco-driver-loader? (or am I missing something?)
We can probably do this too; but since we already do some other stuff in the entrypoint, i assumed that was the best place actually
Although the /proc symlink makes sense in the case you mentioned, how can we generally ensure it matches the same namespace? (ie. mounting the wrong /proc might be worse than not mounting it at all).
That's a good point actually; i am not sure what we can do (aside from failing badly :D )
Since /lib/modules is only required to build the driver, why not put this logic inside falco-driver-loader? (or am I missing something?)
We can probably do this too; but since we already do some other stuff in the entrypoint, i assumed that was the best place actually
I think there's no best practice here :angel: and I'm not yet sure putting it into falco-driver-loader is the best thing to do.
I would like to manage this more consistently. @falcosecurity/falco-maintainers WDYT?
Although the /proc symlink makes sense in the case you mentioned, how can we generally ensure it matches the same namespace? (ie. mounting the wrong /proc might be worse than not mounting it at all).
That's a good point actually; i am not sure what we can do (aside from failing badly :D )
I'll move this to 0.36 since we are still looking for a general consensus :D /milestone 0.36.0
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
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
@FedeDP: Closed this PR.
In response to this:
/close
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.