Elastisys Compliant Kubernetes is an open source, Certified Kubernetes distribution designed according to the ISO27001 controls: providing you with security tooling and observability from day one.
Overriding Falco rules requires deep knowledge about Falco and its rules, and the format is essentially half yaml half their own conditions, but we expose this in it's entirety as a string.
We should change this so that we keep rules managed, with a simple configuration structure, with well defined macros that can be overridden.
Proposed alternatives
Example:
falco:
additions:
lists:
trusted_images:
- reg.example.com/img
macros:
trusted_users:
- user.loginid = 1001
rules:
run_shell_untrusted:
- and image.name in trusted_image
- and trusted_user
And this renders down into additional lists and macros first, and this is merge:able from common config except the content of arrays will be overriden from sc/wc config.
All should have prefixes and in the correct order to ensure that they cannot interfere with already set rules.
For each "rule" in the config we then provide a macro we manage that the "rule" is added into, then finally we add this macro into the overrideable macro provided from upstream along with any built in changes.
Additional context
This way we have:
a clear list of supported rules to add to,
a clear way to create lists and macros from config to use in rule additions,
prohibit the override of lists and macros which can cause confusion, and requires knowledge about the available lists and macros, and which may interfere with rules set in apps,
provide clear structure that can be reused for internal overrides done in apps.
It might still be good to expose overrides for unsupported rules, however it should:
Proposed features
Overriding Falco rules requires deep knowledge about Falco and its rules, and the format is essentially half yaml half their own conditions, but we expose this in it's entirety as a string.
We should change this so that we keep rules managed, with a simple configuration structure, with well defined macros that can be overridden.
Proposed alternatives
Example:
And this renders down into additional lists and macros first, and this is merge:able from common config except the content of arrays will be overriden from sc/wc config. All should have prefixes and in the correct order to ensure that they cannot interfere with already set rules.
For each "rule" in the config we then provide a macro we manage that the "rule" is added into, then finally we add this macro into the overrideable macro provided from upstream along with any built in changes.
Additional context
This way we have:
It might still be good to expose
overrides
for unsupported rules, however it should:Definition of done