Enable "Admin Area > Network > User and IP Rate Limits" on GitLab.com
Dogfooding problem
GitLab.com does not dogfood Admin Area > Network > User and IP Rate Limits: https://docs.gitlab.com/ee/user/gitlab_com/index.html#admin-area-settings
As GitLab evolves, new bugs are created. Customers using Admin Area > Network > User and IP Rate Limits are forced to discover these bugs, report them, and push them to be fixed. Dogfooding is the most appropriate way to handle this problem. There isn't a good reason for us not to do this.
I informally asked about enabling this after first implementing it, but I did not follow up as I should have.
Noisy neighbor problem
From &1737:
Make GitLab more stable and robust against unintentional or intentional abuses and scenarios where "noisy neighbours" (users, projects, groups) are able to disrupt the whole instance by just doing one action (for example push XX.000 tags, post 10000 comments to an issue through a bot, etc.).
From https://docs.gitlab.com/ee/user/admin_area/settings/user_and_ip_rate_limits.html:
The following limits can be enforced in Admin Area > Network > User and IP rate limits:
Unauthenticated requests Authenticated API requests Authenticated web requestsThese limits are disabled by default.
Proposal
-
Enable rate limits in Admin Area > Network > User and IP Rate Limits, initially with high limits -
Lower the limits as desired
https://docs.gitlab.com/ee/user/admin_area/settings/user_and_ip_rate_limits.html
This is safe because the limits can be easily raised or disabled at any time in UI.
Eventually, I would personally like to expand Admin Area > Network > User and IP Rate Limits functionality so we can remove the arcane, opaque, restart-requiring Rack Attack initializer https://docs.gitlab.com/ee/security/rack_attack.html.