ユーザーとIPレート制限

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

以下の制限はデフォルトで無効になっています:

• 認証されていないAPIリクエスト（IPごと）。
• 認証されていないWebリクエスト（IPごと）。
• 認証されたAPIリクエスト（ユーザーごと）。
• 認証されたWebリクエスト（ユーザーごと）。

認証されていないAPIリクエストレート制限を有効にする

認証されていないAPIリクエストレート制限を有効にするには、次の手順に従います:

1. 左側のサイドバーの下部で、管理者を選択します。

2. 設定 > ネットワークを選択します。

3. ユーザーとIPレートの制限とIPレート制限を展開します。

4. 認証されていないAPIリクエストレート制限を有効にするを選択します。

   • オプション。IPあたりのレート制限期間あたりの最大未認証APIリクエスト数の値を更新します。3600がデフォルトです。
   • オプション。Unauthenticated rate limit period in seconds（認証されていないレート制限期間 (秒)）の値を更新します。3600がデフォルトです。

未認証のウェブリクエストレート制限を有効にする

認証されていないリクエストレート制限を有効にするには、次の手順に従います:

1. 左側のサイドバーの下部で、管理者を選択します。

2. 設定 > ネットワークを選択します。

3. ユーザーとIPレートの制限とIPレート制限を展開します。

4. 未認証のウェブリクエストレート制限を選択します。

   • オプション。IPあたりのレート制限期間あたりの最大未認証webリクエスト数の値を更新します。3600がデフォルトです。
   • オプション。Unauthenticated rate limit period in seconds（認証されていないレート制限期間 (秒)）の値を更新します。3600がデフォルトです。

認証されたAPIリクエストレート制限を有効にする

認証されたAPIリクエストレート制限を有効にするには、次の手順に従います:

1. 左側のサイドバーの下部で、管理者を選択します。

2. 設定 > ネットワークを選択します。

3. ユーザーとIPレートの制限とIPレート制限を展開します。

4. 認証されたAPIリクエストのレート制限を有効にするを選択します。

   • オプション。ユーザーあたりのレート制限期間あたりの最大認証API要求数の値を更新します。7200がデフォルトです。
   • オプション。**認証されたAPIレート制限期間(秒単位)**の値を更新します。3600がデフォルトです。

認証されたWebリクエストレート制限を有効にする

認証されたリクエストレート制限を有効にするには、次の手順に従います:

1. 左側のサイドバーの下部で、管理者を選択します。

2. 設定 > ネットワークを選択します。

3. ユーザーとIPレートの制限とIPレート制限を展開します。

4. 認証されたAPIリクエストレート制限を有効にするを選択します。

   • オプション。ユーザーあたりのレート制限期間あたりの最大認証されたウェブリクエスト数の値を更新します。7200がデフォルトです。
   • オプション。**認証されたWebレート制限期間(秒単位)**の値を更新します。3600がデフォルトです。

カスタムレート制限レスポンスを使用する

レート制限を超過するリクエストは、429レスポンスコードとプレーンテキストの本文を返します。これはデフォルトではRetry laterです。

カスタムレスポンスを使用するには、次の手順に従います:

1. 左側のサイドバーの下部で、管理者を選択します。
2. 設定 > ネットワークを選択します。
3. ユーザーとIPレートの制限とIPレート制限を展開します。
4. **レート制限に達したクライアントに送信するプレーンテキストの応答。**テキストボックスに、プレーンテキストの応答メッセージを追加します。

1分あたりのproject/:id/jobsへの最大認証済みリクエスト

タイムアウトを減らすために、project/:id/jobsエンドポイントには、認証済みユーザーあたり600呼び出しのデフォルトのレート制限があります。

リクエストの最大数を変更するには、次の手順に従います:

1. 左側のサイドバーの下部で、管理者を選択します。
2. 設定 > ネットワークを選択します。
3. ユーザーとIPレートの制限とIPレート制限を展開します。
4. project/:id/jobsへの1分あたりの最大認証リクエスト数の値を更新します。

レスポンスヘッダー

クライアントが関連付けられているレート制限を超えると、次のリクエストはブロックされます。サーバーは、リクエスタが特定の期間後に再試行できるように、レート制限情報で応答する場合があります。これらの情報は、レスポンスヘッダーに添付されます。

HTTPヘッダーを使用してレート制限を回避する

組織のニーズによっては、レート制限を有効にしても、一部のリクエストがレート制限を回避するようにすることがあります。

カスタムヘッダーを使用して、レート制限を回避するリクエストをマークすることで、これを行うことができます。これは、GitLabの前のロードバランサーまたはリバースプロキシ内のどこかで行う必要があります。例:

1. 回避ヘッダーの名前を選択します。たとえばGitlab-Bypass-Rate-Limitingなどです。
2. GitLabレート制限を回避する必要があるリクエストでGitlab-Bypass-Rate-Limiting: 1を設定するようにロードバランサーを設定します。
3. ロードバランサーを次のいずれかに設定します:
   • Gitlab-Bypass-Rate-Limitingを消去します。
   • レート制限の影響を受けるすべてのリクエストで、Gitlab-Bypass-Rate-Limitingを1以外の値に設定します。
4. GITLAB_THROTTLE_BYPASS_HEADERという環境変数を設定します。
   • Linuxパッケージを使用しているセルフコンパイルインストールの場合は、'GITLAB_THROTTLE_BYPASS_HEADER' => 'Gitlab-Bypass-Rate-Limiting'をgitlab_rails['env']に設定します。
   • セルフコンパイルインストールの場合は、export GITLAB_THROTTLE_BYPASS_HEADER=Gitlab-Bypass-Rate-Limitingを/etc/default/gitlabに設定します。

ロードバランサーが、すべての受信トラフィックの回避ヘッダーを消去または上書きすることが重要です。そうしないと、ユーザーがそのヘッダーを設定せず、GitLabのレート制限を回避しないことを信頼する必要があります。

回避は、ヘッダーが1に設定されている場合にのみ機能します。

回避ヘッダーが原因でレート制限を回避したリクエストは、production_json.logで"throttle_safelist":"throttle_bypass_header"でマークされます。

回避メカニズムを無効にするには、環境変数GITLAB_THROTTLE_BYPASS_HEADERが設定されていないか、空であることを確認してください。

特定のユーザーが認証されたリクエストレート制限を回避できるようにする

前に説明した回避ヘッダーと同様に、特定のユーザーセットがレート制限を回避できるようにすることができます。これは認証されたリクエストにのみ適用されます。認証されていないリクエストでは、定義上、GitLabはユーザーが誰であるかを知りません。

許可リストは、環境変数GITLAB_THROTTLE_USER_ALLOWLISTのコンマ区切りのユーザーIDのリストとして設定されます。ユーザー1、53、217が認証されたリクエストレート制限を回避できるようにする場合、許可リストの設定は1,53,217になります。

• Linuxパッケージを使用しているセルフコンパイルインストールの場合は、'GITLAB_THROTTLE_USER_ALLOWLIST' => '1,53,217'をgitlab_rails['env']に設定します。
• セルフコンパイルインストールの場合は、export GITLAB_THROTTLE_USER_ALLOWLIST=1,53,217を/etc/default/gitlabに設定します。

ユーザー許可リストが原因でレート制限を回避したリクエストは、production_json.logで"throttle_safelist":"throttle_user_allowlist"でマークされます。

アプリケーションの起動時に、許可リストはauth.logにログメッセージが記録されます。

スロットル設定を適用する前に試してみる

GITLAB_THROTTLE_DRY_RUN環境変数をスロットル名のコンマ区切りリストに設定して、スロットル設定を試すことができます。

可能な名前は次のとおりです:

• throttle_unauthenticated
  • GitLab 14.3で非推奨になりました。代わりにthrottle_unauthenticated_apiまたはthrottle_unauthenticated_webを使用してください。throttle_unauthenticatedは引き続きサポートされており、両方を選択します。
• throttle_unauthenticated_api
• throttle_unauthenticated_web
• throttle_authenticated_api
• throttle_authenticated_web
• throttle_unauthenticated_protected_paths
• throttle_authenticated_protected_paths_api
• throttle_authenticated_protected_paths_web
• throttle_unauthenticated_packages_api
• throttle_authenticated_packages_api
• throttle_authenticated_git_lfs
• throttle_unauthenticated_files_api
• throttle_authenticated_files_api
• throttle_unauthenticated_deprecated_api
• throttle_authenticated_deprecated_api

たとえば、保護されていないパスへのすべての認証済みリクエストに対してスロットルを試すには、GITLAB_THROTTLE_DRY_RUN='throttle_authenticated_web,throttle_authenticated_api'を設定して実行できます。

すべてのスロットルのドライランモードを有効にするには、変数を*に設定します。

スロットルをドライランモードに設定すると、制限に達した場合に、auth.logにメッセージがログメッセージ記録され、リクエストは続行されます。ログメッセージには、envフィールドにtrackが設定されたenvが含まれています。matchedフィールドには、ヒットしたスロットルの名前が含まれています。

設定でレート制限を有効にする前に、環境変数を設定することが重要です。管理者エリアの設定はすぐに有効になりますが、環境変数を設定するには、すべてのPumaプロセスを再起動する必要があります。

トラブルシューティング

管理者が誤ってブロックされた後、スロットルを無効にする

多数のユーザーが同じプロキシまたはネットワークゲートウェイを介してGitLabに接続する場合、レート制限が低すぎると、スロットルをトリガーしたリクエストと同じIPを使用しているとGitLabが認識するため、その制限によって管理者もブロックされる可能性があります。

管理者は、Railsコンソールを使用して、GITLAB_THROTTLE_DRY_RUN変数にリストされているものと同じ制限を無効にすることができます。例:

Gitlab::CurrentSettings.update!(throttle_authenticated_web_enabled: false)

この例では、throttle_authenticated_webパラメータには_enabledという名前のサフィックスが付いています。

制限の数値を設定するには、_enabledという名前のサフィックスを_period_in_secondsおよび_requests_per_periodというサフィックスに置き換えます。