-
Notifications
You must be signed in to change notification settings - Fork 417
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
Events and Scope flags #3262
Events and Scope flags #3262
Conversation
c85a0b7
to
d615b39
Compare
1519a5f
to
f3621a1
Compare
3ee0b5e
to
cb2201e
Compare
--filter openat.context.processName=ls | only trace 'openat' events that have 'processName' equal to 'ls' | ||
--filter security_file_open.context.container | only trace 'security_file_open' events coming from a container | ||
--filter comm=bash --filter follow | trace all events that originated from bash or from one of the processes spawned by bash | ||
Scope examples: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@yanivagman I kept both --help event
and --help scope
showing the same help message since they have a lot in common (operators info above). But let me know if we must split it as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Event flag only has a subset of the operators, and can have its own help message.
Yet I think it's ok to keep it like that for now.
We can address this in a future PR
cb2201e
to
0ea668f
Compare
0ea668f
to
dfbd913
Compare
dfbd913
to
e1f8238
Compare
e1f8238
to
c460974
Compare
c460974
to
67e06f8
Compare
This commit splits the '--filter' flag into two new flags: '--scope' and '--events'. The '--scope' flag is used to specify the scope of the events to be captured like 'comm', 'binary', 'pid', 'uid', 'mntns', 'pidns', 'uts', 'tree', 'follow' and 'container', while the '--events' flag is used to specify the events and their userland filters like 'args', 'retval' and 'context'. It also removes the set option previously available for the '--filter' flag, as it is no longer needed. The '--events' flag is now used to specify the sets of events to be captured, e.g. '--events fs'. Other chores: - analyze '--event' flag now is '--events', to be consistent. - polcy_file.go validateContext() is removed since we have similar validation in further stages. - Relocates unit tests from flags_test.go to respective new correlated files, making it easier to maintain and extend and changes integration tests to use PolicyFile instead of Policy. BREAKING CHANGE: '--filter' flag is now replaced by '--scope' and '--events' flags and analyze '--event' flag is now '--events'. Co-authored-by: Yaniv Agman <yanivagman@gmail.com>
67e06f8
to
3429c8e
Compare
// TODO: decide if we want to bind this flag to viper, since we already have a similar | ||
// flag in rootCmd, conflicting with each other. | ||
// The same goes for the other flags (signatures-dir, rego), also in rootCmd. | ||
// | ||
// err := viper.BindPFlag("events", analyze.Flags().Lookup("events")) | ||
// if err != nil { | ||
// fmt.Fprintf(os.Stderr, "Error: %s\n", err) | ||
// os.Exit(1) | ||
// } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've detected viper flags conflicts between rootCmd and analyze. The same viper instance is being used, which means that the settings have to be defined in the global config file. But rootCmd events (former filter) is a flag designedly not bound to the global config file as we can see below.
But there are other conflicts like signatures-dir and rego, both already bound in the rootCmd.
I suppose that analyze events flag is not a global config flag, right? So, probably we can remove these mentioned bindings in analyze. WDYT @josedonizetti?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@geyslan I believe this is related: spf13/viper#233
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@geyslan I believe this is related: spf13/viper#233
Thanks for the reference. A possible solution, if we decide to bind these flags to global config file, is to do it in PreRun()
, so it won't override as in init()
: spf13/viper#233 (comment)
For now, leaving them commented.
@yanivagman ready for review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some nit comments, but otherwise LGTM
Co-authored-by: Yaniv Agman <yanivagman@gmail.com>
Co-authored-by: Yaniv Agman <yanivagman@gmail.com>
Co-authored-by: Yaniv Agman <yanivagman@gmail.com>
Co-authored-by: Yaniv Agman <yanivagman@gmail.com>
@yanivagman @rafaeldtinoco @josedonizetti, just a note to, when merging this, squash the commits leaving the message of the main one as it is (the other commits were just review suggestions accepted directly in github). |
Synced offline and merging it. |
After the changes of aquasecurity#3262, at this stage, policies.Map() length is always greater than 0.
After the changes of aquasecurity#3262, at this stage, policies.Map() length is always greater than 0.
After the changes of aquasecurity#3262, at this stage, policies.Map() length is always greater than 0.
After the changes of aquasecurity#3262, at this stage, policies.Map() length is always greater than 0.
After the changes of aquasecurity#3262, at this stage, policies.Map() length is always greater than 0.
After the changes of #3262, at this stage, policies.Map() length is always greater than 0.
After the changes of aquasecurity#3262, at this stage, policies.Map() length is always greater than 0.
1. Explain what the PR does
Close #2810
Close #3261
Close #1543
3429c8e feat(cmd/flags)!: split filter flag (2023/jun/29) Geyslan Gregório <geyslan@gmail.com>
2. Explain how to test it
See documentation changes.
3. Other comments
This is the continuation of #3100.