アウトバウンドリクエストのフィルタリング

GitLab管理者は、データ損失や暴露のリスクから保護するために、アウトバウンドリクエストフィルタリングコントロールを使用して、GitLabインスタンスによって行われる特定のアウトバウンドリクエストを制限できるようになりました。

セキュアなWebhookとインテグレーション

少なくともメンテナーのロールを持つユーザーは、プロジェクトやグループで特定の変更が発生したときにトリガーされるWebhookを設定できます。トリガーされると、POST HTTP リクエストが URL に送信されます。Webhook は通常、特定の外部 Web サービスにデータを送信するように設定され、適切な方法でデータを処理します。

しかし、Webhook は外部 Web サービスの代わりに内部 Web サービスの URL で設定することもできます。Webhookがトリガーされると、GitLabサーバーまたはそのローカルネットワークで実行されているGitLab以外のWebサービスが悪用される可能性があります。

WebhookリクエストはGitLabサーバー自身によって行われ、作成者の代わりにフックごとに1つのシークレットトークン（オプション）を使用します：

  • ユーザートークン。
  • リポジトリ固有のトークン。

その結果、これらのリクエストは、Webhook をホストしているサーバー上で動作しているすべてのものへのアクセスを含む、意図したよりも広い範囲のアクセスを持つことができます：

  • GitLab サーバー。
  • API 自体。
  • 一部の Webhook については、Webhook サーバーのローカルネットワーク内の他のサーバーへのネットワークアクセス。

Webhook を使えば、認証を必要としないウェブサービスを使って破壊的なコマンドを起動することができます。これらのWebhookは、リソースを削除するエンドポイントへのPOST HTTPリクエストをGitLabサーバーに行わせることができます。

Webhook とインテグレーションからローカルネットワークへのリクエストを許可します。

前提条件

  • インスタンスへの管理者アクセス権が必要です。

安全でない内部 Web サービスの悪用を防ぐため、以下のローカル・ネットワーク・アドレスへのすべての Webhook およびインテグレーション・リクエストは許可されません：

  • 現在の GitLab インスタンスサーバーのアドレス。
  • 127.0.0.1,::1,0.0.0.0,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16, および IPv6 サイトローカル (ffc0::/10) アドレスを含む非公開ネットワークアドレス。

これらのアドレスへのアクセスを許可するには、次の手順に従います：

  1. 左のサイドバーで、Search を選択するか、次のページに進んでください。
  2. Admin Areaを選択します。
  3. 左サイドバーで、「設定」 > 「ネットワーク」を選択します。
  4. 送信要求］を展開します。
  5. Webhook とインテグレーションからのローカルネットワークへのリクエストを許可する] チェックボックスを選択します。

システムフックからのローカルネットワークへのリクエストを禁止

前提条件

  • インスタンスへの管理者アクセス権が必要です。

システム・フックはデフォルトでローカル・ネットワークへのリクエストを行うことができます。ローカル・ネットワークへのシステム・フックの要求を防ぐには、以下の手順に従います：

  1. 左のサイドバーで、Search を選択するか、次のページに進んでください。
  2. Admin Areaを選択します。
  3. 左サイドバーで、「設定」 > 「ネットワーク」を選択します。
  4. 送信要求］を展開します。
  5. システムフックからのローカルネットワークへの要求を許可] チェックボックスをオフにします。

リクエストのフィルタ

GitLab 15.10 で導入されました。

前提条件

  • GitLabインスタンスへの管理者権限が必要です。

多くのリクエストをブロックしてフィルタリングするには

  1. 左のサイドバーで、Search を選択するか、次のページに進んでください。
  2. Admin Areaを選択します。
  3. 左サイドバーで、「設定」 > 「ネットワーク」を選択します。
  4. 送信要求］を展開します。
  5. 許可リストに定義されている IP アドレス、IP 範囲、およびドメイン名を除く、すべての要求をブロックする] チェックボックスを選択します。

このチェックボックスが選択されている場合でも、以下への要求はブロックされません：

  • Geo、Git、GitLab Shell、Gitaly、PostgreSQL、RedisなどのCoreサービス。
  • オブジェクトストレージ。
  • 許可リストのIPアドレスとドメイン。

この設定はメインのGitLabアプリケーションによってのみ尊重されるので、Gitalyのような他のサービスはまだルールを破るリクエストをすることができます。さらに、GitLabのいくつかの領域はアウトバウンドフィルタリングルールを尊重しません。

特定のIPアドレスとドメインへのアウトバウンドリクエストを許可します。

GitLab 12.2で導入されました。

前提条件

  • インスタンスへの管理者アクセス権が必要です。

特定の IP アドレスとドメインへのアウトバウンド・リクエストを許可するには、次のようにします：

  1. 左のサイドバーで、Search を選択するか、次のページに進んでください。
  2. Admin Areaを選択します。
  3. 左サイドバーで、「設定」 > 「ネットワーク」を選択します。
  4. 送信要求］を展開します。
  5. フックとインテグレーションがアクセスできるローカルIPアドレスとドメイン名］に、IPアドレスとドメインを入力します。

入力できるのは

  • セミコロン、カンマ、または空白 (改行を含む) で区切ります。
  • ホスト名、IPアドレス、IPアドレス範囲など、異なる形式であること。IPv6に対応しています。Unicode文字を含むホスト名は、Applications (IDNA) エンコーディングの国際化ドメイン名を使用してください。
  • ポートを含めること。たとえば、127.0.0.1:8080 は、127.0.0.1のポート 8080 への接続のみを許可します。ポートが指定されていない場合、そのIPアドレスまたはドメインのすべてのポートが許可されます。IP アドレス範囲は、その範囲内のすべての IP アドレス上のすべてのポートを許可します。
  • 各エントリに 255 文字以内で、1000 エントリ以下の数を指定します。
  • ワイルドカードを含まない（例えば、*.example.com ）。

使用例：

example.com;gitlab.example.com
127.0.0.1,1:0:0:0:0:0:0:1
127.0.0.0/8 1:0:0:0:0:0:0:0/124
[1:0:0:0:0:0:0:1]:8080
127.0.0.1:8080
example.com:8080

トラブルシューティング

アウトバウンドリクエストをフィルタリングしていると、次のようなイシューに遭遇することがあります。

設定したURLがブロックされる問題

設定された URL がブロックされない場合にのみ、[許可リストに定義された IP アドレス、IP 範囲、およびドメイン名を除くすべての要求をブロックする] チェックボックスを選択できます。そうしないと、URLがブロックされたというエラーメッセージが表示されることがあります。

この設定を有効にできない場合は、次のいずれかを実行してください：

  • URL設定を無効にします。
  • 別のURLを設定するか、URL設定を空のままにします。
  • 設定したURLを許可リストに追加します。

公開 Runner リリース URL はブロックされます。

ほとんどの GitLab インスタンスではpublic_runner_releases_url がhttps://gitlab.com/api/v4/projects/gitlab-org%2Fgitlab-runner/releasesに設定されており、リクエストのフィルタリングができません。

このイシューを解決するには、GitLab.comからRunnerリリースのバージョンデータを取得しないようにGitLabを設定します。

GitLab サブスクリプション管理がブロックされています。

リクエストをフィルタリングすると、GitLabサブスクリプション管理がブロックされます。

この問題を回避するには、customers.gitlab.com:443 をallowlist に追加してください。