[APPSEC-8112] Appsec allow to set user id denylist

[GustavoCaso]

What does this PR do?
Introduce a new appsec configuration option user_id_denylist

That list would be use to populate the waf rules data at the initialization of a the AppSec::Processor.

Changes in AppSec::Processor:
Previously we had a public method called update_ip_denylist which populated the waf rule data just for the IP denylist. Now that we have multiple configuration points for deny lists we have to change the code to account for that.

I created a new private method update_rules_data_with_static_configured_values that creates all the necessary waf rule data for the different deny list configurations and call the waf handle update_rule_data function once with all the data. I made that change to reduce the number of calls to the handle.

Also, I remove the public function update_ip_denylist from the processor interface. I thought about leaving it public and adding an extra public function update_user_id_denylist, but it seems that those are not needed. Ultimately in the future once Remote Configure is implemented we would have to compute the rules data separate and simply call processor.update_rule_data(data)

[lloeki]

Approving because the public facing API looks correct, nonetheless I feel like changes to the private methods are in order.

[lloeki]

Thinking we might want that to be more general, something like:

merge_to_rule_data('blocked_ips' => Datadog::AppSec.settings.ip_denylist, 'blocked_users' => Datadog::AppSec.settings.user_id_denylist)

And a companion:

def apply_denylist(settings)
  update_rule_data(merge_to_rule_data('blocked_ips' => settings.ip_denylist, 'blocked_users' => settings.user_id_denylist))
end

# usage: apply_denylist(Datadog::AppSec.settings)

WDYT?

[GustavoCaso]

I like the suggestion.

One thing that I do not think is necessary right now is the merge_to_rule_data method. If we see that the merging logic gets complicated or that we use it in other places of the codebase we could consider creating the method and exposing it as part of the Processor API.

But for now I think this is readable enough:

def apply_denylist_data(settings)
  ruledata_setting = []
  ruledata_setting << denylist_data('blocked_ips', settings.ip_denylist)
  ruledata_setting << denylist_data('blocked_users', settings.user_id_denylist)

  update_rule_data(ruledata_setting)
end

[lloeki]

Fair enough

[lloeki]

Wondering if we should rather resolve to a default here:

Suggested change

	options[:user_id_denylist] = value
	options[:user_id_denylist] = value || []

[GustavoCaso]

I like that. That way the setting of sane defaults happen at the right layer 😄

[GustavoCaso]

@lloeki I actually change the location in which we return the default empty array. Rather than on the setter I returned an empty array at the time of reading the value of client_ip_denylist or user_id_denylist if nothing has been configured.

Check 296b62b

[lloeki]

Cool. I think this also makes it more testable