Add rate limiting bypass mechanism triggered by HTTP header
What does this MR do?
Part of gitlab-com/gl-infra/scalability#624 (closed). Also see rationale in gitlab-com/gl-infra/scalability#622 (closed).
The built-in HTTP request rate limiting feature of GitLab is currently not usable on gitlab.com because it is not granular enough. The limits we apply should depend on the endpoint and who is making the requests. The way we currently handle that is with HAproxy Access Control Lists based on IP addresses and HAproxy rate limiting. This MR presents an minimal feature that lets us keep the HAproxy ACL's but shift the rate limiting to GitLab. The idea is that HAproxy sets a header on requests that match the allow-list.
The most important thing this will unlock is rate limiting per user across the entire surface of the application. We cannot turn this on at the moment because we need to allow-list some IP's and that allow-listing will be made possible by this bypass mechanism.
For pragmatic reasons this feature is implemented in a very minimal way.
- This feature has been stuck for a long time and by keeping it minimal we can now actually get it done
- By leaving existing responsibilities (matching allow-listed requests) with HAproxy we minimize change and thereby reduce risk, which is desirable for gitlab.com availability
Screenshots (strongly suggested)
In the spirit of keeping things minimal the bypass header is configured via an environment variable GITLAB_THROTTLE_BYPASS_HEADER so there is nothing to show in screenshots.
Does this MR meet the acceptance criteria?
Conformity
-
Changelog entry -
Documentation (if required) -
Code review guidelines -
Merge request performance guidelines -
Style guides -
Database guides -
Separation of EE specific content
Availability and Testing
-
Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process. -
Tested in all supported browsers -
Informed Infrastructure department of a default or new setting change, if applicable per definition of done
Security
If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:
-
Label as security and @ mention @gitlab-com/gl-security/appsec -
The MR includes necessary changes to maintain consistency between UI, API, email, or other methods -
Security reports checked/validated by a reviewer from the AppSec team