falco
falco copied to clipboard
falcosecurity
Source configuration from multiple files
Motivation
I would like to ship Falco with my personal distro, providing a default /etc/falco/falco.yaml file with sensible values however I would also like users to be able to customize the configuration by adding output channels (and other options), overwriting the defaults I am providing.
If I were to ship the /etc/falco/falco.yaml and the user edits it, the file is no longer managed by my OS and upgrades are no longer applied when I roll them out.
Feature
It would be great if Falco allowed a configuration input which accepts a list of configuration files which it sources from at startup. This input could, like the rules_file parameter, point to files or directories such as /etc/falco/config.yaml or /etc/falco/config.d which the user can add and remove files from safely, without gaining ownership of the primary /etc/falco/falco.yaml file.
The proposed configuration could therefore look like this:
# /etc/falco/falco.yaml
config_file:
- /etc/falco/config.yaml
- /etc/falco/config.local.yaml
- /etc/falco/config.d
The falco.yaml file would have the least priority, followed by the files defined in config_file input and finally in-line options would keep the highest priority.
Alternatives
Alternatively, I believe I can ship my custom configuration inline (in systemd units) but the user will not be able to overwrite these configurations in the falco.yaml.
Additional context
Upon further searching, this looks to be similar to https://github.com/falcosecurity/falco/issues/2880
Hi @p5 :wave: !
Would you be open to iterate on alternatives a bit more? From our perspective we would like to not introduce more config options unless we gain a lot of value.
Typically you should lots of options to distribute environment specific configurations. Falco ships with a default falco.yaml file but you should always be able to override it easily or point to a custom path via using the -c cmd flag. Eager to understand the limitations in more detail.
[Btw you can also always override individual configs via cmd args, see https://github.com/falcosecurity/falco/blob/master/falco.yaml#L83]
Of course!
So my requirement is users should be able to (easily) overwrite the configuration I (as a distro maintainer) provide in a separate location to the primary configuration that I ship.
If I provide my distro's default configuration in-line (-o) and require users to edit /etc/falco/falco.yaml, I would assume my in-line configuration has a higher priority than the YAML configuration file (as this is usually the case with CLI tooling). So that mostly rules using -o flag out since users will not be able to overwrite my configuration without going into the systemd units.
If I point the configuration to a custom path (-c), this will still be a single configuration file which will be owned by the user once they make a change. If I push an update to the file (as a distribution maintainer) when a system user has already changed the file, my configuration will be ignored and that file no longer receives updates.
Since submitting this issue, I found another request (https://github.com/falcosecurity/falco/issues/2880) in your GitHub Issues which asks for allowing configuration in a falco.local.yaml file, but I believe the implementation described in my issue would be a bit more scalable and allow for more flexible configuration. It allows the author to reference their falco.local.yaml from the primary falco.yaml, but also allows configuration to be sourced from elsewhere.
An example of the sort of configuration I would like to provide is this directory, where people can safely source more scripts in their system bash shell without messing with /etc/bashrc, managed by the distro.
Note: I say "distro maintainer", but take that very loosely. I run my own project that ships a spin of Fedora, and am a maintainer of a larger project - Universal Blue. I am investigating if we can integrate it there too for a more security-focused distro, or include it in ucore - a CoreOS server spin.
I see your use case is very different from a regular deployment, as I would have suggested to have some central configuration location where you manage your environment specific deployments. Plus you are tied to a systemd unit deployment model only.
Let's see what the other maintainers say to adding additional config surface in this regard. I am still on the fence in terms of value add for the broader community.
/milestone TBD
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
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Provide feedback via https://github.com/falcosecurity/community. /close
@poiana: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity.
Reopen the issue with
/reopen.Mark the issue as fresh with
/remove-lifecycle rotten.Provide feedback via https://github.com/falcosecurity/community. /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.
Hi! I think this was indeed perfectly implemented by https://github.com/falcosecurity/falco/pull/3024 (can't believe I didn't notice that this feat request existed and went on implementing exactly how you described it 🤣 ). The feat is now released as part of Falco 0.38.0, and is described in the release blog post:https://falco.org/blog/falco-0-38-0
Feel free to leave any feedback here or eventually opening another issue.
/milestone 0.38.0
@FedeDP: The provided milestone is not valid for this repository. Milestones in this repository: [0.39.0, 1.0.0, TBD]
Use /milestone clear to clear the milestone.
In response to this:
Hi! I think this was indeed perfectly implemented by https://github.com/falcosecurity/falco/pull/3024 (can't believe I didn't notice that this feat request existed and went on implementing exactly how you described it 🤣 ). The feat is now released as part of Falco 0.38.0, and is described in the release blog post:https://falco.org/blog/falco-0-38-0
Feel free to leave any feedback here or eventually opening another issue.
/milestone 0.38.0
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.
Hi! I think this was indeed perfectly implemented by #3024 (can't believe I didn't notice that this feat request existed and went on implementing exactly how you described it 🤣 ). The feat is now released as part of Falco 0.38.0, and is described in the release blog post:falco.org/blog/falco-0-38-0
Feel free to leave any feedback here or eventually opening another issue.
/milestone 0.38.0
Absolutely amazing! Will take another look at implementing it! The implementation is perfect, and exactly how this issue suggested :laughing: