レート制限

プラン: Free、Premium、Ultimate
提供形態: GitLab Self-Managed、GitLab Dedicated

GitLab.comの場合、GitLab.com固有のレート制限を参照してください。

レート制限は、Webアプリケーションのセキュリティと耐久性を向上させるためによく使用される手法です。

たとえば、簡単なスクリプトで1秒あたり数千件のWebリクエストを送信できます。リクエストは次のいずれかである可能性があります:

悪意のある。
無関心。
単なるバグ。

アプリケーションとインフラストラクチャが負荷に対応できない可能性があります。詳細については、サービス拒否を参照してください。ほとんどの場合、単一のIPアドレスからのリクエストのレート制限によって軽減できます。

ほとんどの総当たり攻撃も同様に、レート制限によって軽減されます。

APIリクエストのレート制限は、これらのリクエストが常にWebトラフィックとしてカウントされるため、フロントエンドからのリクエストには影響しません。

設定可能なレート制限

これらのレート制限は、インスタンスの管理者エリアで設定できます:

これらのレート制限は、ApplicationSettings APIを使用して設定できます:

オートコンプリートユーザーのレート制限

これらのレート制限は、Railsコンソールを使用して設定できます:

Webhookのレート制限

Gitとコンテナレジストリの認証失敗によるBAN

単一のIPアドレスから3分間に30回の認証失敗リクエストを受信した場合、GitLabは1時間403のHTTPステータスコードを返します。これは、以下を組み合わせた場合にのみ適用されます:

Gitリクエスト。
コンテナレジストリ (/jwt/auth) リクエスト。

この制限は、次のようになります:

認証に成功したリクエストでリセットされます。たとえば、29回の認証失敗リクエストの後に1回の成功リクエストがあり、その後にさらに29回の認証失敗リクエストが続いても、BANはトリガーされません。
gitlab-ci-tokenで認証されたJSON Webトークンリクエストには適用されません。
デフォルトでは無効になっています。

応答ヘッダーは提供されません。

レート制限を回避するには、次の方法があります:

自動パイプラインの実行を段階的に行います。
認証の試行に指数バックオフと再試行を設定します。
ドキュメント化されたプロセスとベストプラクティスを使用して、トークンの有効期限を管理します。

設定情報については、Linuxパッケージの設定オプションを参照してください。

設定できない制限

リポジトリアーカイブ

リポジトリアーカイブのダウンロードのレート制限が利用可能です。この制限は、プロジェクトと、UIまたはAPIを介してダウンロードを開始するユーザーに適用されます。

rate limit（レート制限）は、ユーザーあたり1分あたり5リクエストです。

Webhookのテスト

Webhookのテストにはレート制限があり、Webhook機能の悪用を防ぎます。

rate limit（レート制限）は、ユーザーあたり1分あたり5リクエストです。

/users/sign_upエンドポイントには、IPアドレスごとのレート制限があります。これは、エンドポイントの誤用を試みることを軽減するためです。たとえば、使用中のユーザー名またはメールアドレスを大量に検出します。

rate limit（レート制限）は、IPアドレスあたり1分あたり20コールです。

ユーザー名の更新

ユーザー名を変更できる頻度には、レート制限があります。これは、機能の誤用を軽減するために実施されます。たとえば、使用中のユーザー名を大量に検出します。

rate limit（レート制限）は、認証済みユーザーあたり1分あたり10コールです。

ユーザー名の存在

選択したユーザー名がすでに使用されているかどうかを確認するためにサインアップ時に使用される内部エンドポイント/users/:username/existsには、レート制限があります。これは、使用中のユーザー名の大規模な発見など、誤用のリスクを軽減するためです。

rate limit（レート制限）は、IPアドレスあたり1分あたり20コールです。

プロジェクトジョブAPIエンドポイント

ジョブの取得時にタイムアウトを減らすために適用されるエンドポイントproject/:id/jobsには、レート制限があります。

rate limit（レート制限）は、認証済みユーザーあたり、デフォルトで600コールです。レート制限を設定できます。

AIアクション

このエンドポイントの悪用を防ぐために適用されるGraphQLaiActionミューテーションには、レート制限があります。

rate limit（レート制限）は、認証済みユーザーあたり8時間あたり160コールです。

APIを使用したメンバーの削除

APIエンドポイントを使用してプロジェクトまたはグループメンバーを削除する/groups/:id/membersまたは/project/:id/membersには、レート制限があります。

rate limit（レート制限）は、1分あたり60件の削除です。

リポジトリのblobとファイルアクセス

レート制限は、特定リポジトリAPIエンドポイントを介して大きなファイルにアクセスするときに適用されます。10 MBを超えるファイルの場合、レート制限は、オブジェクトごと、プロジェクトごとに1分あたり5コールです:

リポジトリblobエンドポイント：/projects/:id/repository/blobs/:sha
リポジトリファイルエンドポイント：/projects/:id/repository/files/:file_path

これらの制限は、APIを介して大規模なリポジトリファイルにアクセスする際の過度のリソース使用を防ぐのに役立ちます。

通知メール

プロジェクトまたはグループに関連する通知メールには、レート制限があります。

rate limit（レート制限）は、プロジェクトまたはグループごと、ユーザーあたり24時間あたり1,000件の通知です。

GitHubのインポート

GitHubからのプロジェクトのインポートのトリガーには、レート制限があります。

rate limit（レート制限）は、ユーザーあたり1分あたり6つのトリガーされたインポートです。

FogBugzのインポート

FogBugzからのプロジェクトのインポートのトリガーには、レート制限があります。

rate limit（レート制限）は、ユーザーあたり1分あたり1つのトリガーされたインポートです。

コミット差分ファイル

これは、展開されたコミット差分ファイル（/[group]/[project]/-/commit/[:sha]/diff_files?expanded=1）のレート制限であり、このエンドポイントの悪用を防ぐために適用されます。

rate limitは、ユーザー（認証済みユーザー）またはIPアドレス（認証なし）あたり1分あたり6リクエストです。

変更履歴の生成

:id/repository/changelogエンドポイントには、プロジェクトごとにユーザーごとのレート制限があります。これは、エンドポイントの誤用を試みることを軽減するためです。レート制限は、GETアクションとPOSTアクションの間で共有されます。

rate limit（レート制限）は、プロジェクトごとにユーザーあたり1分あたり5コールです。

トラブルシューティング

Rack Attackがロードバランサーを拒否リストに登録している

すべてのトラフィックがロードバランサーから送信されているように見える場合、Rack Attackがロードバランサーをブロックする可能性があります。その場合は、次の操作を行う必要があります:

nginx[real_ip_trusted_addresses]を設定します。これにより、ユーザーのIPがロードバランサーのIPとしてリストされなくなります。
許可リストロードバランサーのIPアドレス。
GitLabを再設定します:
```
sudo gitlab-ctl reconfigure
```

Redisを使用して、Rack AttackからブロックされたIPを削除する

ブロックされたIPを削除するには:

実稼働ログでブロックされているIPを見つけます:
```
grep "Rack_Attack" /var/log/gitlab/gitlab-rails/auth.log
```
拒否リストはRedisに保存されているため、redis-cliを開く必要があります:
```
/opt/gitlab/embedded/bin/redis-cli -s /var/opt/gitlab/redis/redis.socket
```
次の構文を使用してブロックを削除できます。<ip>を拒否リストに登録されている実際のIPに置き換えます:
```
del cache:gitlab:rack::attack:allow2ban:ban:<ip>
```
IPを含むキーが表示されなくなったことを確認します:
```
keys *rack::attack*
```
デフォルトでは、keysコマンドが無効になっています。
オプションで、許可リストにIPを追加して、再度拒否リストに登録されないようにします。