### Why The epic says the rack-attack gem stays because `Rack::Attack::Allow2Ban` has no labkit equivalent. That is the last thing keeping the gem in the Gemfile after phase 3. This issue is the work to close that gap. ### What Allow2Ban does for us today One caller: `Gitlab::Auth::IpRateLimiter` (`lib/gitlab/auth/ip_rate_limiter.rb`), used from `Gitlab::Auth.find_for_git_client` (`lib/gitlab/auth.rb:121`) for Git HTTP basic auth and container-registry JWT auth. Three operations, all keyed by IP: - `banned?` → `Allow2Ban.banned?(ip)`. Called before the credential checks; a ban raises `Gitlab::Auth::IpBlocked`, handled in `ApplicationController`, `JwtController` and `Gitlab::Middleware::Go`. - `register_fail!` → `Allow2Ban.filter(ip, config) { true }`. Called after a failed auth attempt. - `reset!` → `Allow2Ban.reset(ip, config)`. Called after a successful one, because Git clients routinely send an unauthenticated first request and we don't want that to count. All three no-op when the feature is off or the IP is in `ip_whitelist`. Config comes from `Gitlab.config.rack_attack.git_basic_auth` (`config/initializers/1_settings.rb:836-841`): `enabled`, `ip_whitelist`, `maxretry`, `findtime`, `bantime`. On GitLab.com those are `enabled: true, maxretry: 300, findtime: 60, bantime: 900` (`k8s-workloads/gitlab-com/releases/gitlab/values/values.yaml.gotmpl:903`); the Rails default is `maxretry: 10, findtime: 1.minute, bantime: 1.hour`. ### The semantic gap Labkit counts within a fixed window and tells you whether you are over the limit. Allow2Ban does something else: N failures inside `findtime` write a separate ban key with its own `bantime` TTL, and the ban outlives the counter window. So 2 separate keys, each with a different TTL. Labkit has neither half of that. `Rule` has no `ban` action, the evaluator never writes a second key on threshold, and there is no delete API, so `reset!` maps to nothing. None of that is an adapter swap. Three ways I can see to close it: 1. Count in labkit, keep the ban in the app. A rule counts failures per IP over `findtime`, and `IpRateLimiter` writes and reads its own ban key. No labkit change at all, but we keep hand-rolled Redis in gitlab-rails, which is the thing we are trying to get away from. 2. Add a `ban` action to labkit. The rule declares `ban_for:`, the evaluator writes a ban key on threshold, and later checks short-circuit on it. Needs a `reset`/`clear` API too, for the success path. Faithful to what we have, biggest labkit change, and it wants a design pass alongside [#28853](https://gitlab.com/gitlab-com/gl-infra/production-engineering/-/work_items/28853). 3. Drop the ban concept. N failures per IP per window, nothing else. Users would notice: a banned IP recovers after `findtime` instead of `bantime`, which on GitLab.com means 60s instead of 900s. I lean towards 2, but I think we should discuss. Will there be enough use cases to warrant the implementation of a `ban` action? 3 is the easiest to do in the short term, but that's a breaking change for self-managed installations. In either approach, the `ip_whitelist` can become a `skip` rule in Labkit terms. Which means we'll have observability over it the same way we have for all rules. ### Things that come along with it - `Gitlab::RackAttack::Store` (`lib/gitlab/rack_attack/store.rb`) exists to point Allow2Ban at `Gitlab::Redis::RateLimiting` with a `cache:gitlab:` namespace. It goes away with the last Allow2Ban caller. Note [#29543](https://gitlab.com/gitlab-com/gl-infra/production-engineering/-/work_items/29543) explicitly keeps the `Rack::Attack.cache.store` assignment alive for Allow2Ban's sake, so this issue unblocks that cleanup. - The Redis keys change shape. Today: `cache:gitlab:rack::attack:allow2ban:ban:<ip>`. Labkit uses `labkit:rl:<limiter>:<rule>:...`. `doc/rate_limits/_index.md:294` documents the old key for unbanning an IP and needs rewriting, along with the ja-jp translation. - In-flight bans are abandoned at deploy. With `bantime: 900` on GitLab.com that is a 15-minute window where some already-banned IPs get a fresh start. Acceptable, worth saying out loud. - The `Rack_Attack` log message in `Gitlab::Auth.rate_limit!` (`lib/gitlab/auth.rb:198`) and the `log_ip_blocked` entries in `ApplicationController`/`JwtController`/`Go` all say `Rack_Attack`. Renaming breaks anyone grepping auth.log, including our own docs at `doc/rate_limits/_index.md:281`. Probably worth doing anyway, but as a deliberate call. - Removing `gem 'rack-attack'` from the Gemfile is the closing step, after [#29543](https://gitlab.com/gitlab-com/gl-infra/production-engineering/-/work_items/29543) and [#29545](https://gitlab.com/gitlab-com/gl-infra/production-engineering/-/work_items/29545). ### Testing `spec/lib/gitlab/auth/ip_rate_limiter_spec.rb` mocks `Rack::Attack::Allow2Ban` directly, so it gets rewritten. `spec/requests/git_http_spec.rb` has four blocks (lines 568, 617, 1094, 1481) that stub or reset Allow2Ban; those are the real behavioral coverage and should keep testing behavior, not the new internals. ### Sequencing Depends on [#29543](https://gitlab.com/gitlab-com/gl-infra/production-engineering/-/work_items/29543) (middleware removal) only for the store cleanup; the migration itself can start earlier. Blocks the gem removal and part of [#29545](https://gitlab.com/gitlab-com/gl-infra/production-engineering/-/work_items/29545). ### Related - [Remove Rack::Attack from the request path](https://gitlab.com/groups/gitlab-com/gl-infra/-/work_items/2109) - [#29543 Remove the Rack::Attack middleware from the request path](https://gitlab.com/gitlab-com/gl-infra/production-engineering/-/work_items/29543) - [#29545 Retire the Gitlab::RackAttack namespace](https://gitlab.com/gitlab-com/gl-infra/production-engineering/-/work_items/29545) - [#28853 Design: Rate limit configuration evolution](https://gitlab.com/gitlab-com/gl-infra/production-engineering/-/work_items/28853) if we go with option 2, since a `ban` action is a config-model question too