ユーザーおよびIPレート制限

レート制限は、ウェブアプリケーションのセキュリティと耐久性を向上させるために使用される一般的なテクニックです。詳細はレート制限を参照してください。

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

note
デフォルトでは、すべてのGitオペレーションはまず認証なしで試されます。このため、HTTP Git オペレーションは認証されていないリクエストに対して設定されたレート制限をトリガーする可能性があります。
note
GitLab 14.8以降では、APIリクエストのレートリミットはフロントエンドからのリクエストには影響しません。

認証されていないAPIリクエストのレートリミットを有効にします。

認証されていないリクエストのレート制限を有効にします：

  1. 左のサイドバーで、Search を選択するか、次のページに進んでください。
  2. Admin Areaを選択します。
  3. 設定 > ネットワークを選択します。
  4. ユーザーとIPレート制限を展開します。

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

    • オプション。IP値ごとのレート制限期間あたりの最大未認証APIリクエスト］を更新します。デフォルトは3600 です。
    • オプション。認証なしレート制限期間（秒）］を更新します。デフォルトは3600です。

認証されていない Web 要求のレート制限を有効にします。

認証されていないリクエストのレート制限を有効にします：

  1. 左のサイドバーで、Search を選択するか、次のページに進んでください。
  2. Admin Areaを選択します。
  3. 設定 > ネットワークを選択します。
  4. ユーザーとIPレート制限を展開します。

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

    • オプション。IP ごとのレート制限期間あたりの最大未認証 Web 要求］を更新します。デフォルトは3600 です。
    • オプション。認証なしレート制限期間（秒）］を更新します。デフォルトは3600です。

認証済みAPIリクエストのレート制限を有効にします。

認証済み API リクエストのレート制限を有効にします：

  1. 左のサイドバーで、Search を選択するか、次のページに進んでください。
  2. Admin Areaを選択します。
  3. 設定 > ネットワークを選択します。
  4. ユーザーとIPレート制限を展開します。

  5. 認証済みAPIリクエストのレート制限を有効にする]を選択します。

    • オプション。ユーザーごとのレート制限期間あたりの最大認証 API 要求数を更新します。デフォルトは7200です。
    • オプション。Authenticated API rate limit period in seconds］の値を更新します。デフォルトは3600です。

認証済み Web 要求のレート制限を有効にします。

認証されていないリクエストのレート制限を有効にします：

  1. 左のサイドバーで、Search を選択するか、次のページに進んでください。
  2. Admin Areaを選択します。
  3. 設定 > ネットワークを選択します。
  4. ユーザーとIPレート制限を展開します。

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

    • オプション。ユーザーごとのレート制限期間あたりの最大認証 Web 要求数を更新します。デフォルトは7200 です。
    • オプション。Authenticated web rate limit period in seconds] を更新します。デフォルトは3600 です。

カスタム速度制限応答を使用します。

GitLab 13.8 で導入されました。

レート制限を超えたリクエストは429 レスポンスコードとプレーンテキストのボディを返します。デフォルトではRetry later です。

カスタムレスポンスを使うには

  1. 左のサイドバーで、Search を選択するか、次のページに進んでください。
  2. Admin Areaを選択します。
  3. 設定 > ネットワークを選択します。
  4. ユーザーとIPレート制限を展開します。
  5. レート制限にヒットしたクライアントに送信するプレーンテキストの応答］テキストボックスに、プレーンテキストの応答メッセージを追加します。

応答ヘッダー

GitLab 13.8 で導入された、RateLimit ヘッダです。Retry-After は以前のバージョンで導入されました。

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

ヘッダ物件例説明
RateLimit-Limit60 分ごとのクライアントのリクエストクォータ。管理領域で設定されているレートリミットの期間が 1 分と異なる場合、このヘッダの値は直近の 60 分に調整されます。
RateLimit-Namethrottle_authenticated_webリクエストをブロックしているスロットルの名前。
RateLimit-Observed67タイムウィンドウ内のクライアントに関連付けられたリクエスト数。
RateLimit-Remaining0時間ウィンドウの残りクォータ。RateLimit-Limit -RateLimit-Observed の結果。
RateLimit-Reset1609844400リクエストクォータがリセットされるUnix時間フォーマットの時間。
RateLimit-ResetTimeTue, 05 Jan 2021 11:00:00 GMTリクエストクォータがリセットされるRFC2616 形式の日付と時刻。
Retry-After30クォータがリセットされるまでの残り時間 (秒)。これは標準の HTTP ヘッダです。

HTTPヘッダを使用してレート制限をバイパスします。

GitLab 13.6で導入されました。

組織のニーズによっては、レート制限を有効にしつつも一部のリクエストはレート制限をバイパスさせたいこともあるでしょう。

その場合は、カスタムヘッダでレートリミッタをバイパスするリクエストをマークします。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_rails['env'] に'GITLAB_THROTTLE_BYPASS_HEADER' => 'Gitlab-Bypass-Rate-Limiting' を設定します。
    • セルフ・コンパイル・インストールの場合は、/etc/default/gitlab のexport GITLAB_THROTTLE_BYPASS_HEADER=Gitlab-Bypass-Rate-Limiting を設定してください。

ロードバランサーはすべての受信トラフィックのバイパスヘッダを消去するか上書きすることがインポートです。さもなければ、ユーザーがそのヘッダーを設定せず、GitLabのレートリミッターをバイパスしないことを信頼しなければなりません。

バイパスはヘッダーが1 に設定されている場合にのみ機能します。

バイパスヘッダのためにレートリミッターをバイパスしたリクエストは、production_json.log で"throttle_safelist":"throttle_bypass_header" とマークされます。

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

特定のユーザーが認証されたリクエストレート制限をバイパスできるようにします。

GitLab 13.7 で導入されました。

上記のbypassヘッダと同様に、特定のユーザーに対してレートリミッタをバイパスすることを許可することができます。これは認証されたリクエストにのみ適用されます。認証されていないリクエストでは、定義上GitLabはユーザーが誰であるかを知りません。

allowlist はカンマ区切りのユーザー ID のリストとしてGITLAB_THROTTLE_USER_ALLOWLIST 環境変数に設定します。ユーザー 1、53、217 に認証済みリクエストのレートリミッターをバイパスさせたい場合は、allowlist の設定は1,53,217 となります。

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

ユーザー許可リストのためにレートリミッターをバイパスしたリクエストは、production_json.log の"throttle_safelist":"throttle_user_allowlist" でマークされます。

アプリケーションの起動時に、allowlist はauth.log に記録されます。

スロットリングの設定を強制する前に試してみてください。

GitLab 13.6で導入されました。

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 にメッセージをログに記録します。ログメッセージはtrack に設定されたenv フィールドを含みます。matched フィールドはヒットしたスロットルの名前を含みます。

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