レート制限
- プラン: Free、Premium、Ultimate
- 提供形態: GitLab Self-Managed、GitLab Dedicated
GitLab.comについては、GitLab.com固有のレート制限を参照してください。
GitLab Dedicatedについては、認証済みユーザーレート制限を参照してください。
レート制限は、Webアプリケーションのセキュリティと耐久性を向上させるための一般的な手法です。
たとえば、単純なスクリプトで毎秒数千ものWebリクエストを生成できます。リクエストは次のいずれかの可能性があります:
- 悪意のあるもの。
- 無関心なもの。
- 単なるバグ。
お使いのアプリケーションとインフラストラクチャは、この負荷に対応できない可能性があります。詳細については、サービス拒否を参照してください。ほとんどのケースは、単一のIPアドレスからのリクエストのレートを制限することで軽減できます。
ほとんどのブルートフォース攻撃も、同様にレート制限によって軽減されます。
APIリクエストに対するレート制限は、フロントエンドで行われたリクエストには影響しません。これらのリクエストは常にWebトラフィックとしてカウントされるためです。
構成可能な制限
これらのレート制限は、インスタンスの管理者エリアで設定できます:
- インポート/エクスポートレート制限
- イシューレート制限
- ノートレート制限
- 保護されたパス
- rawエンドポイントレート制限
- ユーザーとIPレート制限
- パッケージレジストリレート制限
- Git LFSレート制限
- Git SSHオペレーションのレート制限
- ファイルAPIレート制限
- 非推奨APIレート制限
- GitLab Pagesレート制限
- パイプラインレート制限
- インシデント管理レート制限
- プロジェクトAPIレート制限
- グループAPIレート制限
- ユーザーAPIレート制限
- 組織APIレート制限
これらのレート制限は、ApplicationSettings APIを使用して設定できます:
これらのレート制限は、Railsコンソールを使用して設定できます:
Gitおよびコンテナレジストリの認証失敗BAN
単一のIPアドレスから3分間に30件の認証失敗リクエストが受信された場合、GitLabは1時間HTTPステータスコード403を返します。これは、以下の組み合わせにのみ適用されます:
- Gitリクエスト。
- コンテナレジストリ (
/jwt/auth) リクエスト。
この制限は、次のようになります。
- 認証に成功したリクエストでリセットされます。例えば、29回の認証失敗リクエスト、それに続く1回の成功したリクエスト、さらに29回の認証失敗リクエストという場合、BANはトリガーされません。
gitlab-ci-tokenで認証されたJSON Webトークンリクエストには適用されません。- デフォルトで無効になっています。
応答ヘッダーは提供されません。
レート制限を回避するには、次のことができます:
- 自動化されたパイプラインの実行をずらす。
- 失敗した認証試行のために、指数関数的バックオフとリトライを構成します。
- ドキュメント化されたプロセスとベストプラクティスを使用して、トークンの有効期限を管理します。
設定情報については、Linuxパッケージ設定オプションを参照してください。
設定できない制限
リポジトリアーカイブ
リポジトリアーカイブのダウンロードのレート制限が利用可能です。この制限は、UIまたはAPIを通じてダウンロードを開始するプロジェクトおよびユーザーに適用されます。
レート制限は、ユーザーあたり1分間に5リクエストです。
Webhookテスト
Webhookのテストにはレート制限があり、Webhook機能の悪用を防ぎます。
レート制限は、ユーザーあたり1分間に5リクエストです。
ユーザー登録
/users/sign_upエンドポイントには、IPアドレスあたりのレート制限があります。これは、エンドポイントの悪用を軽減するためのものです。例えば、使用中のユーザー名やメールアドレスの一括発見などです。
レート制限は、IPアドレスあたり1分間に20呼び出しです。
ユーザー名の更新
ユーザー名の変更頻度にはレート制限があります。これは、機能の悪用を軽減するために適用されます。例えば、どのユーザー名が使用中であるかを一括で発見するためなどです。
レート制限は、認証済みユーザーあたり1分間に10呼び出しです。
ユーザー名が存在します
選択したユーザー名がすでに使用されているかを確認するためのサインアップ時に使用される内部エンドポイント/users/:username/existsには、レート制限があります。これは、使用中のユーザー名の一括発見などの悪用リスクを軽減するためのものです。
レート制限は、IPアドレスあたり1分間に20呼び出しです。
プロジェクトジョブAPIエンドポイント
ジョブの取得時にタイムアウトを減らすために適用されるエンドポイントproject/:id/jobsには、レート制限があります。
レート制限は、認証済みユーザーあたり600呼び出しにデフォルト設定されています。レート制限を構成できます。
AIアクション
GraphQL aiActionミューテーションにはレート制限があり、このエンドポイントの悪用を防ぐために適用されます。
レート制限は、認証済みユーザーあたり8時間で160呼び出しです。
APIを使用したメンバーの削除
APIエンドポイントを使用したプロジェクトまたはグループメンバーの削除 (/groups/:id/membersまたは/project/:id/members) には、レート制限があります。
レート制限は1分間に60削除です。
APIを使用したプロジェクトメンバーのリスト表示
グループまたはプロジェクト内のすべてのプロジェクトメンバーをリスト表示するためのレート制限を設定します。次のエンドポイントでは、デフォルトで1分あたり200リクエストに設定されています:
GET /groups/:id/members/all
GET /projects/:id/members/all管理者は、プロジェクトエンドポイントのレート制限を構成できます。
リポジトリblobとファイルアクセス
特定のリポジトリAPIエンドポイントを介して大きなファイルにアクセスする場合に、レート制限が適用されます。10 MBを超えるファイルの場合、レート制限はオブジェクトあたりプロジェクトあたり1分間に5呼び出しです:
- リポジトリblobエンドポイント:
/projects/:id/repository/blobs/:sha - リポジトリファイルエンドポイント:
/projects/:id/repository/files/:file_path
これらの制限は、APIを介して大きなリポジトリファイルにアクセスする際の過剰なリソース使用を防ぐのに役立ちます。
通知メール
プロジェクトまたはグループに関連する通知メールには、レート制限があります。
レート制限は、ユーザーあたりプロジェクトまたはグループあたり24時間で1,000件の通知です。
GitHubインポート
GitHubからのプロジェクトインポートをトリガーするには、レート制限があります。
レート制限は、ユーザーあたり1分間に6回のトリガーされたインポートです。
FogBugzインポート
FogBugzからのプロジェクトインポートをトリガーするには、レート制限があります。
レート制限は、ユーザーあたり1分間に1回のトリガーされたインポートです。
コミット差分ファイル
これは、展開されたコミット差分ファイル (/[group]/[project]/-/commit/[:sha]/diff_files?expanded=1) に対するレート制限であり、このエンドポイントの悪用を防ぐために適用されます。
レート制限は、ユーザーあたり (認証済み) またはIPアドレスあたり (未認証) 1分間に6リクエストです。
変更履歴の生成
:id/repository/changelogエンドポイントには、ユーザーあたりプロジェクトあたりのレート制限があります。これは、エンドポイントの悪用を軽減するためのものです。レート制限は、GETアクションとPOSTアクションの間で共有されます。
レート制限は、ユーザーあたりプロジェクトあたり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が再び拒否リストに追加されるのを防ぐために、IPを許可リストに追加します。