-
Notifications
You must be signed in to change notification settings - Fork 439
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
internal/appsec: refactor listeners #2862
Conversation
Signed-off-by: Eliott Bouhana <[email protected]>
Signed-off-by: Eliott Bouhana <[email protected]>
Signed-off-by: Eliott Bouhana <[email protected]>
Signed-off-by: Eliott Bouhana <[email protected]>
Signed-off-by: Eliott Bouhana <[email protected]>
4cc8228
to
e5b9a43
Compare
Signed-off-by: Eliott Bouhana <[email protected]>
Signed-off-by: Eliott Bouhana <[email protected]>
Signed-off-by: Eliott Bouhana <[email protected]>
Signed-off-by: Eliott Bouhana <[email protected]>
Signed-off-by: Eliott Bouhana <[email protected]>
Signed-off-by: Eliott Bouhana <[email protected]>
Signed-off-by: Eliott Bouhana <[email protected]>
Signed-off-by: Eliott Bouhana <[email protected]>
BenchmarksBenchmark execution time: 2024-09-23 15:08:27 Comparing candidate commit d730a85 in PR branch Found 9 performance improvements and 1 performance regressions! Performance is the same for 48 metrics, 1 unstable metrics. scenario:BenchmarkExtractW3C-24
scenario:BenchmarkInjectW3C-24
scenario:BenchmarkPartialFlushing/Disabled-24
scenario:BenchmarkPartialFlushing/Enabled-24
scenario:BenchmarkSetTagMetric-24
scenario:BenchmarkSingleSpanRetention/no-rules-24
scenario:BenchmarkSingleSpanRetention/with-rules/match-all-24
scenario:BenchmarkSingleSpanRetention/with-rules/match-half-24
scenario:BenchmarkStartSpan-24
scenario:BenchmarkTracerAddSpans-24
|
Signed-off-by: Eliott Bouhana <[email protected]>
Signed-off-by: Eliott Bouhana <[email protected]>
Signed-off-by: Eliott Bouhana <[email protected]>
Signed-off-by: Eliott Bouhana <[email protected]>
Signed-off-by: Eliott Bouhana <[email protected]>
FYI The Orchestrion Job error has been identified and is independent from this PR |
Signed-off-by: Eliott Bouhana <[email protected]>
…odules Signed-off-by: Eliott Bouhana <[email protected]>
RequestURI: r.RequestURI, | ||
Host: r.Host, | ||
RemoteAddr: r.RemoteAddr, | ||
Headers: r.Header, |
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.
We need to allow use of the functor that allows synchronizing access to the headers here, don't we?
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 you are talking about rapid stuff it's on response headers not the request one. And if you don't talk about rapid stuff:
- Concurrent access from the middlewares above us is not supposed to happen at all following the spec
- I just copied the previous behaviour
} | ||
|
||
// RunSimple runs the WAF with the given address data and returns an error that should be forwarded to the caller | ||
func RunSimple(ctx context.Context, addrs waf.RunAddressData, errorLog string) error { |
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.
This function does not filter the addresses to only retain what's supported... any particular reason?
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 will call the function (*ContextOperation).Run
via the (*ContextOperation).OnEvent
eventually so it's still filtered
return !ok | ||
}) | ||
|
||
result, err := ctx.Run(addrs) |
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.
At this point, addrs
could be empty, and if it is, do we really need to submit to the WAF?
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.
This is done by in the first line of the Run function on go-libddwaf side so....
Signed-off-by: Eliott Bouhana <[email protected]>
Co-authored-by: Romain Marcadier <[email protected]>
Signed-off-by: Eliott Bouhana <[email protected]>
What does this PR do?
This reorders and moves a lot of appsec logic under dyngo for a greater flexibility and less code duplication. Noteworthy changes are:
internal/appsec/trace
package, distributed between listeners packagesemitter/waf
package containing theContextOperation
which merge the code fromhttpsec
,grpcsec
andgraphqlsec
operations. This made possible to create thewaf.RunEvent
event listener that will simply to a WAF run and dispatch actions events if deemed necessary by the WAF.trace.TagsHolder
became thetrace.ServiceEntrySpanOperation
andtrace.SpanOperation
. They are now always the top level operations to make the link between APM and ASM. They also can receive events with span tags from higher in the stack to create various span tags. All span tags setting code is now under the listeners because of this change.emitter/waf/addresses
package to store WAF addresses and awaf.RunAddressDataBuilder
builder to provide a hassle-free API when dealing with lower-level free-form API shenanigans of the WAF.wafEventListeners
array filled at init time to a full-fledged API calledFeature
's (feel free to find a better name) to register listeners. Its purpose is to be a list of pure functions depending only on the merged configuration with no side-effets and ready to be re-built at each config change.usersec
package to better work on login eventsemitter/waf/actions
(with some simplification ofc)Reviewer's Checklist
Unsure? Have a question? Request a review!