オフライン環境
- プラン: Free、Premium、Ultimate
- 提供形態: GitLab Self-Managed
オフライン環境をセットアップするには、購入前にクラウドライセンスのオプトアウト免除を受ける必要があります。詳細については、GitLabの営業担当者にお問い合わせください。
インターネットに接続していなくても、ほとんどのGitLabセキュリティスキャナーを実行できます。
このドキュメントでは、セキュアカテゴリー(つまり、スキャナーの種類)をオフライン環境で操作する方法について説明します。これらの手順は、保護されている、セキュリティポリシー(ファイアウォールポリシーなど)がある、またはインターネットへのフルアクセスが制限されているGitLab Self-Managedインスタンスにも適用されます。GitLabでは、これらの環境を_オフライン環境_と呼んでいます。その他の一般的な名前は次のとおりです:
- エアギャップ環境
- 接続が制限された環境
- ローカルエリアネットワーク(LAN)環境
- イントラネット環境
これらの環境には、インターネットアクセスを防止または制限する物理的な障壁またはセキュリティポリシー(ファイアウォールなど)があります。これらの手順は、物理的に切断されたネットワーク向けに設計されていますが、他のユースケースでも実行できます。
オフライン環境の定義
オフライン環境では、GitLabインスタンスは、ローカルネットワーク上で通信できる1つ以上のサーバーとサービスである可能性がありますが、インターネットへのアクセスはまったくないか、非常に制限されています。GitLabインスタンスおよびサポートインフラストラクチャ(プライベートMavenリポジトリなど)内のものはすべて、ローカルネットワーク接続を介してアクセスできると想定します。インターネットからのファイルは、物理メディア(USBドライブ、ハードドライブ、書き込み可能なDVDなど)を介して入手する必要があると想定します。
オフラインスキャナーの使用
GitLabスキャナーは通常、インターネットに接続して、署名、ルール、パッチの最新セットをダウンロードします。ローカルネットワーク上で利用可能なリソースを使用してツールが適切に機能するように設定するには、いくつかの追加手順が必要です。
コンテナイメージレジストリとパッケージリポジトリ
大まかに言うと、セキュリティスキャナーはDockerイメージとして提供され、さまざまなパッケージリポジトリを利用する場合があります。インターネットに接続されたGitLabインストールでジョブを実行すると、GitLabはGitLab.comでホストされているコンテナイメージレジストリをチェックし、これらのDockerイメージの最新バージョンがあることを確認し、必要に応じてパッケージリポジトリに接続して必要な依存関係をインストールします。
オフライン環境では、GitLab.comにクエリが送信されないように、これらのチェックを無効にする必要があります。GitLab.comのレジストリとリポジトリは利用できないため、異なる内部ホストレジストリを参照するか、個々のスキャナーイメージへのアクセスを提供するために、各スキャナーを更新する必要があります。
また、npm、yarn、Ruby gemなど、GitLab.comでホストされていない一般的なパッケージリポジトリにアプリがアクセスできることを確認する必要があります。これらのリポジトリからのパッケージは、一時的にネットワークに接続するか、独自のオフラインネットワーク内でパッケージをミラーリングすることで取得できます。
脆弱性との対話
脆弱性が見つかると、それを操作できます。脆弱性に対処する方法の詳細をお読みください。
場合によっては、報告された脆弱性に、UIに公開されている外部リンクを含むメタデータが含まれることがあります。これらのリンクは、オフライン環境内ではアクセスできない可能性があります。
脆弱性の解決
脆弱性を解決する機能は、オフラインの依存関係スキャンおよびコンテナスキャンで使用できますが、インスタンスの設定によっては機能しない場合があります。その依存関係またはイメージの最新バージョンをホストする最新のレジストリサービスにアクセスできる場合にのみ、通常はパッチが適用された最新バージョンであるソリューションを提案できます。
スキャナーの署名とルールの更新
インターネットに接続すると、一部のスキャナーは、チェック対象となる署名とルールの最新セットについて、公開データベースを参照します。接続がない場合、これは不可能です。スキャナーによっては、これらの自動更新チェックを無効にし、付属のデータベースを使用し、それらのデータベースを手動で更新するか、ネットワーク内でホストされている独自のコピーへのアクセスを提供する必要があります。
特定スキャナーの手順
個々のスキャナーは、前に説明した手順と若干異なる場合があります。詳細については、以下の各ページをご覧ください:
- コンテナスキャンオフライン手順
- SASTオフライン手順
- シークレット検出オフライン手順
- DASTオフライン手順
- APIファジングオフライン手順
- ライセンススキャンオフライン手順
- Gemnasium: 依存関係スキャンオフライン手順
- IaCスキャンオフライン手順
オフラインホストへのDockerイメージの読み込む
セキュリティスキャンやAuto DevOpsなど、多くのGitLab機能を使用するには、Runnerが関連するDockerイメージをフェッチできる必要があります。
パブリックインターネットに直接アクセスせずにこれらのイメージを利用できるようにするプロセスには、イメージのダウンロード、パッケージ化、およびオフラインホストへの転送が含まれます。そのような転送の例を次に示します:
- パブリックインターネットからDockerイメージをダウンロードします。
- Dockerイメージをtarアーカイブとしてパッケージ化します。
- イメージをオフライン環境に転送します。
- 転送されたイメージをオフラインDockerレジストリに読み込むます。
公式GitLabテンプレートの使用
GitLabには、このプロセスを簡単にするバンドルテンプレートが用意されています。
このテンプレートは、新しい空のプロジェクトで、.gitlab-ci.ymlファイルに次の内容を含めて使用する必要があります:
include:
- template: Security/Secure-Binaries.gitlab-ci.ymlパイプラインは、セキュリティスキャナーに必要なDockerイメージをダウンロードし、ジョブアーティファクトとして保存するか、パイプラインが実行されるプロジェクトのコンテナレジストリにプッシュします。これらのアーカイブは、別の場所に転送し、Dockerデーモンに読み込むことができます。この方法では、gitlab.com(registry.gitlab.comを含む)とローカルコピーのオフラインインスタンスの両方にアクセスできるRunnerが必要です。このRunnerは、ジョブ内でdockerコマンドを使用できるように、特権モードで実行する必要があります。このRunnerは、DMZまたはバスチオンにインストールでき、この特定のプロジェクトでのみ使用できます。
このテンプレートには、コンテナスキャンアナライザーのアップデートは含まれていません。コンテナスキャンオフライン手順を参照してください。
更新のスケジュール
デフォルトでは、このプロジェクトのパイプラインは、.gitlab-ci.ymlがリポジトリに追加されたときに1回だけ実行されます。GitLabセキュリティスキャナーと署名を更新するには、このパイプラインを定期的に実行する必要があります。GitLabには、パイプラインをスケジュールする方法が用意されています。たとえば、毎週Dockerイメージをダウンロードして保存するように、これをセットアップできます。
作成されたセキュアバンドルの使用
Secure-Binaries.gitlab-ci.ymlテンプレートを使用するプロジェクトは、GitLab Security機能を実行するために必要なすべてのイメージとリソースをホストするようになります。
次に、オフラインインスタンスに、GitLab.comのデフォルトのものに代えて、これらのリソースを使用するように指示する必要があります。そのためには、プロジェクトのコンテナレジストリのURLを使用して、CI/CD変数SECURE_ANALYZERS_PREFIXを設定します。
この変数は、プロジェクトの.gitlab-ci.yml、またはプロジェクトまたはグループのGitLab UIで設定できます。詳細については、GitLab CI/CD変数のページを参照してください。
変数
次の表に、Secure-Binaries.gitlab-ci.ymlテンプレートで使用できるCI/CD変数を示します:
| CI/CD変数 | 説明 | デフォルト値 |
|---|---|---|
SECURE_BINARIES_ANALYZERS | ダウンロードするアナライザーのカンマ区切りリスト | "bandit, brakeman, gosec, ..." |
SECURE_BINARIES_DOWNLOAD_IMAGES | ジョブを無効にするために使用 | "true" |
SECURE_BINARIES_PUSH_IMAGES | ファイルをプロジェクトレジストリにプッシュ | "true" |
SECURE_BINARIES_SAVE_ARTIFACTS | イメージアーカイブをアーティファクトとして保存 | "false" |
SECURE_BINARIES_ANALYZER_VERSION | デフォルトアナライザーバージョン(Dockerタグ) | "2" |
公式テンプレートを使用しない別の方法
上記の方法を実行できない場合は、代わりにイメージを手動で転送できます:
イメージパッケージャー</packageャースクリプトの例
#!/bin/bash
set -ux
# Specify needed analyzer images
analyzers=${SAST_ANALYZERS:-"bandit eslint gosec"}
gitlab=registry.gitlab.com/security-products/
for i in "${analyzers[@]}"
do
tarname="${i}_2.tar"
docker pull $gitlab$i:2
docker save $gitlab$i:2 -o ./analyzers/${tarname}
chmod +r ./analyzers/${tarname}
doneイメージローダースクリプトの例
この例では、バスチオンホストからオフラインホストにイメージを読み込むます。特定の設定では、そのような転送に物理メディアが必要になる場合があります:
#!/bin/bash
set -ux
# Specify needed analyzer images
analyzers=${SAST_ANALYZERS:-"bandit eslint gosec"}
registry=$GITLAB_HOST:4567
for i in "${analyzers[@]}"
do
tarname="${i}_2.tar"
scp ./analyzers/${tarname} ${GITLAB_HOST}:~/${tarname}
ssh $GITLAB_HOST "sudo docker load -i ${tarname}"
ssh $GITLAB_HOST "sudo docker tag $(sudo docker images | grep $i | awk '{print $3}') ${registry}/analyzers/${i}:2"
ssh $GITLAB_HOST "sudo docker push ${registry}/analyzers/${i}:2"
doneオフライン環境でのGitLab SecureとAutoDevOpsの使用
オフライン環境でSecureスキャンにGitLab AutoDevOpsを使用できます。ただし、最初に次の手順を実行する必要があります:
コンテナイメージをローカルコピーのレジストリに読み込むます。GitLab Secureは、アナライザーコンテナイメージを活用して、さまざまなスキャンを実行します。これらのイメージは、AutoDevOpsの実行の一部として使用可能である必要があります。AutoDevOpsを実行する前に、公式GitLabテンプレートの手順に従って、それらのコンテナイメージをローカルコピーのコンテナレジストリに読み込むます。
CI/CD変数を設定して、AutoDevOpsがそれらのイメージの適切な場所を確実に探すようにします。AutoDevOpsテンプレートは、アナライザーイメージの場所を識別するために、
SECURE_ANALYZERS_PREFIX変数を利用します。詳細については、作成されたセキュアバンドルの使用を参照してください。この変数を、アナライザーイメージを読み込む場所に適切な値に設定してください。プロジェクトCI/CD変数を使用するか、.gitlab-ci.ymlファイルを直接変更して、これを行うことを検討できます。
これらの手順が完了すると、GitLabにはSecureアナライザーのローカルコピーがあり、インターネットでホストされているコンテナイメージの代わりにそれらを使用するようにセットアップされます。これにより、オフライン環境でAutoDevOpsのSecureを実行できます。
これらの手順は、AutoDevOpsを使用したGitLab Secureに固有のものです。AutoDevOpsで他のステージを使用するには、Auto DevOpsドキュメントに記載されている他の手順が必要になる場合があります。