appsec: allow to load multiple appsec-config per appsec datasource

[blotus]

Currently, only one appsec config is allowed per appsec datasource.
This is quite limiting, as if a user wants to have multiple set of rules (for example, vpatch rules + CRS), they will need to create a custom appsec config, which might or might not get new appsec rules depending on how it is written.

We should allow to load multiple appsec config, each config would be stand-alone (ie, hooks from one config would not affect the other one)

[github-actions]

@blotus: Thanks for opening an issue, it is currently awaiting triage.

In the meantime, you can:

1. Check Crowdsec Documentation to see if your issue can be self resolved.
2. You can also join our Discord.
3. Check Releases to make sure your agent is on the latest version.

Details

I am a bot created to help the crowdsecurity developers manage community feedback and contributions. You can check out my manifest file to understand my behavior and what I can do. If you want to use this for your project, you can check out the BirthdayResearch/oss-governance-bot repository.

[github-actions]

@blotus: There are no 'kind' label on this issue. You need a 'kind' label to start the triage process.

• /kind feature
• /kind enhancement
• /kind refactoring
• /kind bug
• /kind packaging

Details

I am a bot created to help the crowdsecurity developers manage community feedback and contributions. You can check out my manifest file to understand my behavior and what I can do. If you want to use this for your project, you can check out the BirthdayResearch/oss-governance-bot repository.

[LaurenceJJones]

keep for 1.6.3 or not ? @blotus @buixor

[buixor]

Currently, several approaches are possible:

Solution 1 : We merge/concat everything

• We append out of band/Inband Rules and on_load/pre_eval/post_eval/on_match Hooks.

• For all possibly conflicting options ( default_pass_action, default_remediation , blocked_http_code, passed_http_code, user_blocked_http_code and user_passed_http_code) and (disable_body_inspection / request_body_in_memory_limit) the last one take the precedence.

• For Hooks, they are all evaluated in-line, which means that in case of conflicting instructions (ie. SetRemediation), the last one will take the precedence.

# Solution 2 : We deal with them sequentially
We keep each AppsecRuntimeConfig on its own, and we process each of them sequentially

Loking at the code, solution #2 will imply an explosion of memory costs and doesn't look like a viable solution.

[buixor]

fixed in #3314