Rules versioning #492
Merged
Rules versioning #492
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
|
||
|
|
||
| if [ $NEW_CHECKSUM != $CUR_CHECKSUM ]; then | ||
| echo "Set of fields supported by falco/sysdig libraries has changed (new checksum $NEW_CHECKSUM != old checksum $CUR_CHECKSUM)." |
There was a problem hiding this comment.
Nice one! I like this approach.
lorenzo-david
approved these changes
Jan 3, 2019
lorenzo-david
approved these changes
Jan 3, 2019
| # limitations under the License. | ||
| # | ||
|
|
||
| - required_engine_version: 9999999 |
There was a problem hiding this comment.
Not really necessary but just for curiosity... what happens if we write some huge num, negative number, etc.? (e.g. 999999999999999999, -9, etc.)
There was a problem hiding this comment.
It would come down to how lua and c convert the number. The check occurs in lua and lua's number type is a double (floating point double), so I don't think there's a chance of underflow.
mstemm
force-pushed
the
rules-versioning
branch
from
3642ec0
to
6c990cf
Compare
mstemm
force-pushed
the
rules-versioning
branch
2 times, most recently
from
07a7b6a
to
f78a139
Compare
Add ability to print field names only instead of all information about fields (description, etc) using -N cmdline option. This will be used to add some versioning support steps that check for a changed set of fields.
Add a method falco_engine::engine_version() that returns the current engine version (e.g. set of supported fields, rules objects, operators, etc.). It's defined in falco_engine_version.h, starts at 2 and should be updated whenever a breaking change is made. The most common reason for an engine change will be an update to the set of filter fields. To make this easy to diagnose, add a build time check that compares the sha256 output of "falco --list -N" against a value that's embedded in falco_engine_version.h. A mismatch fails the build.
A rules file can now have a field "required_engine_version N". If present, the number is compared to the falco engine version. If the falco engine version is less, an error is thrown.
Add a required version: 2 to one trace file to check the positive case and add a new test that verifies that a too-new rules file won't be loaded.
Rename sysdig/falco to falcosecurity/falco in unit tests.
Currently, falco_rules.yaml is compatible with versions <= 0.13.1 other than the required_engine_version object itself, so keep that line commented out so users can use this rules file with older falco versions. We'll uncomment it with the first incompatible falco engine change.
mstemm
force-pushed
the
rules-versioning
branch
from
4982c82
to
95edabf
Compare
leogr
pushed a commit
to leogr/falco
that referenced
this pull request
May 9, 2022
* Add ability to print field names only Add ability to print field names only instead of all information about fields (description, etc) using -N cmdline option. This will be used to add some versioning support steps that check for a changed set of fields. * Add an engine version that changes w/ filter flds Add a method falco_engine::engine_version() that returns the current engine version (e.g. set of supported fields, rules objects, operators, etc.). It's defined in falco_engine_version.h, starts at 2 and should be updated whenever a breaking change is made. The most common reason for an engine change will be an update to the set of filter fields. To make this easy to diagnose, add a build time check that compares the sha256 output of "falco --list -N" against a value that's embedded in falco_engine_version.h. A mismatch fails the build. * Check engine version when loading rules A rules file can now have a field "required_engine_version N". If present, the number is compared to the falco engine version. If the falco engine version is less, an error is thrown. * Unit tests for engine versioning Add a required version: 2 to one trace file to check the positive case and add a new test that verifies that a too-new rules file won't be loaded. * Rename falco test docker image Rename sysdig/falco to falcosecurity/falco in unit tests. * Don't pin falco_rules.yaml to an engine version Currently, falco_rules.yaml is compatible with versions <= 0.13.1 other than the required_engine_version object itself, so keep that line commented out so users can use this rules file with older falco versions. We'll uncomment it with the first incompatible falco engine change.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Changes to explicitly track the version of both the falco engine and a rules file loaded by the engine. See https://github.com/falcosecurity/falco/wiki/Falco-Rules#versioning for more details.
This depends on
draios/sysdig#1288.