Open blotus opened 5 months ago
@blotus: Thanks for opening an issue, it is currently awaiting triage.
In the meantime, you can:
@blotus: There are no 'kind' label on this issue. You need a 'kind' label to start the triage process.
/kind feature
/kind enhancement
/kind bug
/kind packaging
/area lapi /kind feature
Would be awesome to see this in upcoming release, as a hosting company we need more metadata to track bans done by appsec.
Especially the http_host header, since we have thousands of domains that are protected by appsec 👍
+1. Great suggestion, would definitely use. This could also be used to customize the message that people see on their error page.
Currently, the only way to influence the behaviour of a bouncer when applying a decision is to use the
type
attribute of the decision, but this is not very generic, and bouncers need to explicitly handles them.We could introduce the notion of metadata in decisions to allow for a more generic runtime control of bouncers. For example, let's say we have a scenario called
rate-limiting
whose goal is to detect users abusing a specific endpoint, and we want to return a 429 status code for a short time, using the nginx bouncer. There's no easy way to achieve this at the moment:ban
andcaptcha
remediationWhile you can configure the default return code at the bouncer level, it will apply to all decisions, which is not very elegant.
It would be very useful to be able to set arbitrary metadata in a decision when it is created:
cscli decisions add -i 1.2.3.4 -t ban --metadata '{"status_code": 429}'
When the bouncer fetches the decisions, if there is metadata associated with a specific decision, it would appear in the stream:
Each bouncer would know about specific metadata (for example, all bouncers operating at the HTTP could be aware of the
status_code
attribute), and could change their configuration at runtime for a specific decision based on what they received. In this example, only1.2.3.4
would receive a 429 return code, while all other decisions would use the default specified in the bouncer configuration.