Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Reloading configuration without restarting Falco #432

Closed
mumoshu opened this issue Oct 3, 2018 · 5 comments · Fixed by #457
Closed

Feature Request: Reloading configuration without restarting Falco #432

mumoshu opened this issue Oct 3, 2018 · 5 comments · Fixed by #457

Comments

@mumoshu
Copy link

mumoshu commented Oct 3, 2018

Hey! Thanks a lot for maintaining an awesome project.

I'd like propose this feature, either an ability to reload falco config without restarting, or graceful restarting. So that Falco won't drop events while restarting, which is nice for completeness of monitored activities.

Use-case

My specific use-case for this feature is "falco-operator".

Operator is a common idiom in Kubernetes to pair CRD with a Kubernetes controller, so that CRUD to the custom resources result in updating the state of the app on which the operator is operating.

More specifically, "falco-operator" works by watching changes in custom resources containing falco rules. Any falco rules contained in custom resources are concatenated and form a complete falco config file, that is reloaded into falco.

The benefit of this operator is that, now you can delegate management of falco rules to anyone who uses the Kubernetes cluster, including not only securit yengineers but also application developers.

However, falco requiring a restart to reload the configuration file results in intermittent suspends in behavioral monitoring. I think this is a slight security issue itself. Alternatively, I can make the operator to buffer custom resources changes, batch them, to restart falco less frequently. But it isn't a perfect solution.

@henridf
Copy link
Contributor

henridf commented Oct 3, 2018

Hi @mumoshu very cool to hear you're working on a Falco Operator! Look forward to seeing that.

We're looking at ways to support hot-reloading of config but it requires some pretty invasive changes, so I wouldn't expect it to happen in the near-term.

My recommendation would be to start off with your alternate approach with buffering/batching.

@mumoshu
Copy link
Author

mumoshu commented Oct 3, 2018

Hey. Thanks for your explanation and the recommendation! I do start with the alternative approach.

@mumoshu
Copy link
Author

mumoshu commented Oct 5, 2018

@henridf JFYI, here's my quick and dirty implementation of falco-operator, with the suggested approach of buffering changes for certain periods until actual restarts 😃

A hot-reloading feature in falco would still help it continuously enforce rules.

@henridf
Copy link
Contributor

henridf commented Oct 5, 2018

@mumoshu will take a look at the operator, thanks!

leaving this issue open to track the hot-reloading feature.

mstemm added a commit that referenced this issue Nov 6, 2018
Add a signal handler for SIGHUP that sets a global variable g_restart.

All the real execution of falco was already centralized in a standalone
function falco_init(), so simply exit on g_restart=true and call
falco_init() in a loop that restarts if g_restart is set to true.

Take care to not daemonize more than once and to reset the getopt index
to 1 on restart.

This fixes #432.
@mstemm
Copy link
Contributor

mstemm commented Nov 6, 2018

A fix for this is in #457. On SIGHUP falco will entirely restart its main loop, closing the device for the kernel module and re-reading all config, etc. from scratch.

mstemm added a commit that referenced this issue Nov 6, 2018
Add a signal handler for SIGHUP that sets a global variable g_restart.

All the real execution of falco was already centralized in a standalone
function falco_init(), so simply exit on g_restart=true and call
falco_init() in a loop that restarts if g_restart is set to true.

Take care to not daemonize more than once and to reset the getopt index
to 1 on restart.

This fixes #432.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants