-
Notifications
You must be signed in to change notification settings - Fork 449
Add rules to the pipeline #2439
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
Add rules to the pipeline #2439
Conversation
b3ea657
to
0eb7c2e
Compare
@NDStrahilevitz I tried to address all your comments from the previous PR #2374, let me know if anything passed by. |
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.
First review pass: put some comments.
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.
Tested and LGTM. Great work!
b8e65a0
to
f5b0155
Compare
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 left some comments, doubts and nits for you. Nice work. Let's do another round after some answers and talks. Cheers!
pkg/ebpf/events_engine.go
Outdated
for { | ||
select { | ||
case finding := <-engineOutput: | ||
event, err := FindingToEvent(finding) |
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.
Be aware that eventually you will have to call:
if !t.shouldProcessEvent(event) {
continue
}
in here before sending event to "out" channel. This will happen because the user might have choosen the event (Which is a signature) but they might be filtering the output of such event through args, for example. For now you're using the original event args, but eventually it will be the "finding data", right ? Then you might "filter" out detections as well, just like other events.
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.
@rafaeldtinoco I hadn't considered having finding data as args, but I agree it is weird indeed to keep the original event data, need to think about it though. Do you think it is mandatory for this PR, or can be done in a follow-up for the next release?
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.
If the feature will be a "tech preview" I think it is fine do have an issue and mark it for the next release (considering we are out of time for this one).
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.
It won't be the default solution, for now, the only way to use it will be purposely choose it, also will make sure to note it as experimental on the release notes/docs.
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.
Nice work @josedonizetti!
pkg/ebpf/events_engine.go
Outdated
go func() { | ||
defer close(done) | ||
|
||
<-ctx.Done() | ||
done <- true | ||
}() |
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.
Maybe we can pass ctx to the engine as well instead of having this new done channel?
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.
Yup, I also want to do it, didn't do it here because I want to avoid changing tracee-rules. I'll create a follow-up task as a refactor. Ok?
@@ -54,6 +88,15 @@ func main() { | |||
return err | |||
} | |||
|
|||
// parse arguments must be enabled if the rule engine is part of the pipeline | |||
runner.TraceeConfig.Output.ParseArguments = true |
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.
note: we should eventually get rid of this (see #2177)
} | ||
} | ||
|
||
type fakeSignature struct { |
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 think we have a lot of duplicates of this mock signature, maybe we should export one at the signature
package?
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.
LIke the idea, will create a task as a follow-up refactor, ok?
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.
Yep
f5b0155
to
ad929fe
Compare
ad929fe
to
7fe6862
Compare
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.
All good on my side. Will let you handle the rest of the comments with others, but +1'ing on my side.
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.
LGTM
Initial Checklist
This PRs adds the rule engine to the events pipeline.
Fixes: #2441
How Has This Been Tested?