オフライン環境
GitLabセキュリティスキャナのほとんどをインターネットに接続していない状態で実行することが可能です。
この文書では、オフライン環境でのセキュアカテゴリー（つまりスキャナーの種類）のオペレーションについて説明します。これらの説明は、セキュリティ・ポリシー（例えばファイアウォール・ポリシー）が設定されている、あるいはインターネット全体へのアクセスが制限されている自己管理インストールにも適用されます。GitLabはこれらの環境を_オフライン環境と_呼びます。他の一般的な呼び方としては
- エアギャップ環境
- 限られた接続環境
- ローカルエリアネットワーク(LAN) 環境
- イントラネット環境
このような環境では、物理的な障壁やセキュリティポリシー（例えば、ファイアウォール）によって、インターネットへのアクセスが妨げられたり、制限されたりします。これらの指示は、物理的に切断されたネットワーク用に設計されていますが、他のユースケースにも従うことができます。
オフライン環境の定義
オフライン環境では、GitLabインスタンスはローカルネットワーク上で通信できる1つまたは複数のサーバーとサービスになりますが、インターネットへのアクセスはないか、非常に制限されています。GitLabインスタンスとそれをサポートするインフラストラクチャ（インスタンスンスンス、非公開Mavenリポジトリ）内のすべてのものは、ローカルネットワーク接続を介してアクセスできると仮定します。インターネットからのファイルは物理的なメディア（USBドライブ、ハードドライブ、書き込み可能なDVDなど）を通して入ってこなければならないと仮定します。
概要
GitLabスキャナは通常インターネットに接続し、最新のシグネチャ、ルール、パッチをダウンロードします。ローカルネットワークで利用可能なリソースを使用してツールが適切に機能するように設定するには、いくつかの追加ステップが必要です。
コンテナレジストリとパッケージリポジトリ
高レベルでは、セキュリティアナライザはDockerイメージとして提供され、様々なパッケージリポジトリを活用することができます。インターネットに接続されたGitLabインストール上でジョブを実行すると、GitLabはGitLab.comがホストするコンテナレジストリをチェックして、これらのDockerイメージの最新バージョンがあるかどうかをチェックし、場合によってはパッケージリポジトリに接続して必要な依存関係をインストールします。
オフライン環境では、これらのチェックを無効にしてGitLab.comがクエリされないようにする必要があります。GitLab.comのレジストリやリポジトリは利用できないため、内部でホストされている別のレジストリを参照するか、個々のスキャナイメージにアクセスできるように、各スキャナを更新する必要があります。
また、npm や yarn、Ruby gems など、GitLab.com でホストされていない一般的なパッケージリポジトリにアプリがアクセスできるようにする必要があります。これらのリポジトリからのパッケージは、一時的にネットワークに接続するか、自分のオフラインネットワーク内でパッケージをミラーリングすることで取得できます。
脆弱性との対話
脆弱性が見つかったら、それに対処することができます。脆弱性へのアドレスについては、こちらをご覧ください。
報告された脆弱性のメタデータには、UIに外部リンクが含まれている場合があります。これらのリンクはオフライン環境ではアクセスできない可能性があります。
脆弱性の解決
脆弱性の解決機能は、オフラインの依存関係スキャンとコンテナスキャンで利用できますが、インスタンスの設定によっては機能しない場合があります。その依存関係またはイメージの最新バージョンをホストする最新のレジストリサービスにアクセスできる場合にのみ、一般的にパッチが適用された最新バージョンの解決策を提案できます。
スキャナのシグネチャとルールの更新
インターネットに接続されている場合、一部のスキャナは公開データベースを参照して最新のシグネチャとルールをチェックします。接続がない場合、これは不可能です。したがって、スキャナによっては、これらの自動更新チェックを無効にし、スキャナに付属のデータベースを使用して手動で更新するか、ネットワーク内でホストされている独自のコピーにアクセスできるようにする必要があります。
スキャナに関する具体的な説明
個々のスキャナによって、上記の手順とは若干異なる場合があります。詳しくは以下の各ページをご覧ください：
オフラインホストへの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 または bastion にインストールすることができ、この特定のプロジェクトにのみ使用されます。
更新のスケジューリング
デフォルトでは、このプロジェクトのパイプラインは.gitlab-ci.yml がリポジトリに追加されたときに一度だけ実行されます。GitLab のセキュリティスキャナとシグネチャを更新するには、このパイプラインを定期的に実行する必要があります。GitLab にはパイプラインをスケジュールする方法があります。例えば、毎週Dockerイメージをダウンロードして保存するように設定することができます。
作成したセキュアバンドルを使って
Secure-Binaries.gitlab-ci.yml テンプレートを使ったプロジェクトは、GitLab セキュリティ機能を実行するために必要なイメージとリソースをすべてホストしているはずです。
次に、オフラインインスタンスに GitLab.com のデフォルトリソースの代わりにこれらのリソースを使うように指示する必要があります。そのためには、CI/CD 変数SECURE_ANALYZERS_PREFIX にプロジェクトコンテナレジストリの URL を設定します。
この変数はプロジェクトの.gitlab-ci.yml 、またはGitLab UIのプロジェクトやグループレベルで設定することができます。詳しくはGitLab CI/CD変数のページをご覧ください。
変数
次の表は、Secure-Binaries.gitlab-ci.yml テンプレートで使用できる CI/CD 変数を示しています：
| CI/CD 変数 | 説明 | デフォルト値 |
|---|---|---|
SECURE_BINARIES_ANALYZERS | ダウンロードする分析装置のコンマ区切りリスト | "bandit, brakeman, gosec, and so on..." |
SECURE_BINARIES_DOWNLOAD_IMAGES | ジョブを無効にするために使用します。 | "true" |
SECURE_BINARIES_PUSH_IMAGES | プロジェクトレジストリへのファイルのプッシュ | "true" |
SECURE_BINARIES_SAVE_ARTIFACTS | イメージアーカイブもアーティファクトとして保存 | "false" |
SECURE_BINARIES_ANALYZER_VERSION | アナライザのデフォルトバージョン（Dockerタグ） | "2" |
公式テンプレートを使わない代替方法
上記の方法が不可能な場合は、手動で画像を転送することもできます：
イメージパッケージャースクリプトの例
#!/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
イメージローダースクリプト例
この例では、bastion ホストからオフラインホストにイメージをロードします。設定によっては、このような転送に物理メディアが必要になることがあります：
#!/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
オフライン環境での AutoDevOps と GitLab Secure の使用
オフライン環境で GitLab AutoDevOps for Secure スキャンを使用することができます。ただし、最初に以下の手順を実行する必要があります：
-
コンテナイメージをローカルのレジストリにロードします。GitLab Secureはアナライザー・コンテナ・イメージを活用して様々なスキャンを行います。これらのイメージは、AutoDevOps を実行する一部として利用可能でなければなりません。AutoDevOps を実行する前に、上記の手順に従ってこれらのコンテナ・イメージをローカルのコンテナ・レジストリにロードしてください。
-
CI/CD変数を設定して、AutoDevOpsがこれらのイメージの正しい場所を探すようにします。AutoDevOpsテンプレートは、
SECURE_ANALYZERS_PREFIX変数を活用してアナライザーイメージの場所を特定します。この変数については、作成されたセキュリティバンドルの使用で説明しています。この変数に、アナライザー・イメージをロードした場所の正しい値を設定してください。プロジェクトの CI/CD 変数を使用するか、.gitlab-ci.ymlファイルを直接修正してください。
これらの手順が完了すると、GitLabにはSecureアナライザーのローカルコピーがあり、インターネットにホストされたコンテナイメージの代わりにそれらを使用するように設定されています。これにより、オフライン環境でAutoDevOpsのSecureを実行できるようになります。
これらの手順は、GitLab Secure with AutoDevOpsに特有のものです。AutoDevOps で他のステージを使用するには、Auto DevOps ドキュメントで説明されている他の手順が必要になる場合があります。