コンプライアンスパイプライン（非推奨）
- プラン: Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
この機能は、GitLab 17.3で非推奨となり、19.0で削除される予定です。代わりにパイプライン実行ポリシータイプを使用してください。これは破壊的な変更です。詳細については、移行ガイドを参照してください。
グループオーナーは、他のプロジェクトとは別のプロジェクトでコンプライアンスパイプラインを設定できます。デフォルトでは、ラベル付きプロジェクトのコンプライアンスパイプライン設定（例：.compliance-gitlab-ci.yml）は、パイプライン設定（例：.gitlab-ci.yml）の代わりに実行されます。
ただし、コンプライアンスパイプライン設定は、ラベル付きプロジェクトの.gitlab-ci.ymlファイルを参照して、次のことを行うことができます:
- コンプライアンスパイプラインは、ラベル付きプロジェクトパイプラインのジョブも実行できます。これにより、パイプライン設定の一元管理が可能になります。
- コンプライアンスパイプラインで定義されたジョブと変数は、ラベル付きプロジェクトの
.gitlab-ci.ymlファイル内の変数によって変更できません。
既知の問題により、プロジェクトがダウンストリーム設定を上書きするのを防ぐために、プロジェクトパイプラインは、コンプライアンスパイプライン設定の先頭に最初に含める必要があります。
詳細については、以下を参照してください:
- ラベル付きプロジェクトパイプライン設定からジョブを実行するコンプライアンスパイプラインを設定するための設定例。
- コンプライアンスパイプラインの作成チュートリアル。
パイプライン実行ポリシーの移行
スキャンとパイプラインの適用を統合および簡素化するために、パイプライン実行ポリシーが導入されました。GitLab 17.3ではコンプライアンスパイプラインを非推奨とし、GitLab 19.0ではコンプライアンスパイプラインを削除する予定です。
パイプライン実行ポリシーは、パイプライン実行ポリシーにリンクされている個別のYAMLファイル（たとえば、pipeline-execution.yml）で提供される設定を使用して、プロジェクトの.gitlab-ci.ymlファイルを拡張します。
デフォルトでは、新しいコンプライアンスフレームワークを作成する場合、コンプライアンスパイプラインではなく、パイプライン実行ポリシータイプを使用するように指示されます。
既存のコンプライアンスパイプラインを移行する必要があります。お客様は、できるだけ早くコンプライアンスパイプラインから新しいパイプライン実行ポリシータイプに移行する必要があります。
既存のコンプライアンスフレームワークを移行する
既存のコンプライアンスフレームワークを移行して、パイプライン実行ポリシータイプを使用するには、次の手順に従います:
- 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。
- 左側のサイドバーで、セキュリティ > コンプライアンスセンターを選択します。
- 既存のコンプライアンスフレームワークを編集します。
- 表示されるバナーで、パイプラインをポリシーに移行するを選択して、セキュリティポリシーに新しいポリシーを作成します。
- コンプライアンスパイプラインを削除するには、コンプライアンスフレームワークを再度編集します。
詳細については、セキュリティポリシープロジェクトを参照してください。
移行中にPipeline execution policy error: Job names must be uniqueエラーが発生した場合は、関連するトラブルシューティング情報を参照してください。
ラベル付きプロジェクトへの影響
ユーザーは、コンプライアンスパイプラインが設定されていることを知ることができず、独自のパイプラインがまったく実行されない理由、または自分で定義していないジョブが含まれている理由について混乱する可能性があります。
ラベル付きプロジェクトでパイプラインを作成する場合、コンプライアンスパイプラインが設定されているという表示はありません。プロジェクトレベルでの唯一のマーカーは、コンプライアンスフレームワークラベル自体ですが、このラベルは、フレームワークにコンプライアンスパイプラインが設定されているかどうかを示していません。
したがって、プロジェクトユーザーとコンプライアンスパイプライン設定についてコミュニケーションを取り、不確実性と混乱を軽減します。
複数のコンプライアンスフレームワーク
コンプライアンスパイプラインが設定された複数のコンプライアンスフレームワークを単一のプロジェクトに適用できます。この場合、プロジェクトに適用される最初のコンプライアンスフレームワークのみが、プロジェクトパイプラインにコンプライアンスパイプラインを含みます。
正しいコンプライアンスパイプラインがプロジェクトに含まれていることを確認するには、次の手順に従います:
- プロジェクトからすべてのコンプライアンスフレームワークを削除します。
- 正しいコンプライアンスパイプラインを含むコンプライアンスフレームワークをプロジェクトに適用します。
- 追加のコンプライアンスフレームワークをプロジェクトに適用します。
コンプライアンスパイプラインを設定する
コンプライアンスパイプラインを設定するには、次の手順に従います:
左側のサイドバーで、検索または移動先を選択して、グループを見つけます。
左側のサイドバーで、セキュリティ > Compliance Center（コンプライアンスセンター） を選択します。
フレームワークセクションを選択します。
新規フレームワークセクションを選択し、コンプライアンスフレームワーク設定へのパスを含む、コンプライアンスフレームワークの情報を追加します。
path/file.y[a]ml@group-name/project-nameの形式を使用してください。例:.compliance-ci.yml@gitlab-org/gitlab.compliance-ci.yaml@gitlab-org/gitlab
この設定は、コンプライアンスフレームワークラベルが適用されているプロジェクトに継承されます。コンプライアンスフレームワークラベルが適用されたプロジェクトでは、ラベル付きプロジェクト自身のパイプライン設定の代わりに、コンプライアンスパイプライン設定が実行されます。
ラベル付きプロジェクトでパイプラインを実行しているユーザーは、少なくともコンプライアンスプロジェクトのレポーターロールを持っている必要があります。
スキャンの実行を強制するために使用すると、この機能はスキャン実行ポリシーとオーバーラップする部分があります。これらの2つの機能のユーザーエクスペリエンスを統合していません。
設定例
次の例の.compliance-gitlab-ci.ymlには、ラベル付きプロジェクトのパイプライン設定も実行されるようにするためのincludeキーワードが含まれています。
include: # Execute individual project's configuration (if project contains .gitlab-ci.yml)
- project: '$CI_PROJECT_PATH'
file: '$CI_CONFIG_PATH'
ref: '$CI_COMMIT_SHA' # Must be defined or MR pipelines always use the use default branch
rules:
- if: $CI_PROJECT_PATH != "my-group/project-1" # Must run on projects other than the one hosting this configuration.
# Allows compliance team to control the ordering and interweaving of stages/jobs.
# Stages without jobs defined will remain hidden.
stages:
- pre-compliance
- build
- test
- pre-deploy-compliance
- deploy
- post-compliance
variables: # Can be overridden by setting a job-specific variable in project's local .gitlab-ci.yml
FOO: sast
sast: # None of these attributes can be overridden by a project's local .gitlab-ci.yml
variables:
FOO: sast
image: ruby:2.6
stage: pre-compliance
rules:
- if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS && $CI_PIPELINE_SOURCE == "push"
when: never
- when: always # or when: on_success
allow_failure: false
before_script:
- "# No before scripts."
script:
- echo "running $FOO"
after_script:
- "# No after scripts."
sanity check:
image: ruby:2.6
stage: pre-deploy-compliance
rules:
- if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS && $CI_PIPELINE_SOURCE == "push"
when: never
- when: always # or when: on_success
allow_failure: false
before_script:
- "# No before scripts."
script:
- echo "running $FOO"
after_script:
- "# No after scripts."
audit trail:
image: ruby:2.7
stage: post-compliance
rules:
- if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS && $CI_PIPELINE_SOURCE == "push"
when: never
- when: always # or when: on_success
allow_failure: false
before_script:
- "# No before scripts."
script:
- echo "running $FOO"
after_script:
- "# No after scripts."include定義のrules設定は、ホストプロジェクト自体でコンプライアンスパイプラインを実行できる必要がある場合に、循環的な包含を回避します。コンプライアンスパイプラインがラベル付きプロジェクトでのみ実行される場合は、省略できます。
コンプライアンスパイプラインと、外部でホストされるカスタムパイプライン設定
前の例では、すべてのプロジェクトがパイプライン設定を同じプロジェクトでホストしていることを前提としています。プロジェクトで外部でホストされる設定を使用している場合、設定例は機能しません。詳細については、issue 393960を参照してください。
外部でホストされる設定を使用するプロジェクトでは、次の回避策を試すことができます:
コンプライアンスパイプライン設定例の
includeセクションを調整する必要があります。例えば、include:rulesを使用する場合は次のようになります:include: # If the custom path variables are defined, include the project's external config file. - project: '$PROTECTED_PIPELINE_CI_PROJECT_PATH' file: '$PROTECTED_PIPELINE_CI_CONFIG_PATH' ref: '$PROTECTED_PIPELINE_CI_REF' rules: - if: $PROTECTED_PIPELINE_CI_PROJECT_PATH && $PROTECTED_PIPELINE_CI_CONFIG_PATH && $PROTECTED_PIPELINE_CI_REF # If any custom path variable is not defined, include the project's internal config file as normal. - project: '$CI_PROJECT_PATH' file: '$CI_CONFIG_PATH' ref: '$CI_COMMIT_SHA' rules: - if: $PROTECTED_PIPELINE_CI_PROJECT_PATH == null || $PROTECTED_PIPELINE_CI_CONFIG_PATH == null || $PROTECTED_PIPELINE_CI_REF == null外部パイプライン設定を持つプロジェクトには、CI/CD変数を追加する必要があります。この例では:
PROTECTED_PIPELINE_CI_PROJECT_PATH: 設定ファイルをホストするプロジェクトへのパス（たとえば、group/subgroup/project）。PROTECTED_PIPELINE_CI_CONFIG_PATH: プロジェクト内の設定ファイルへのパス（たとえば、path/to/.gitlab-ci.yml）。PROTECTED_PIPELINE_CI_REF: 設定ファイル取得時に使用する参照（例：main）。
プロジェクトフォークで開始されたマージリクエストのコンプライアンスパイプライン
マージリクエストがフォークで開始された場合、マージされるブランチは通常、フォークにのみ存在します。コンプライアンスパイプラインを持つプロジェクトに対してそのようなマージリクエストを作成すると、前のスニペットがProject <project-name> reference <branch-name> does not exist!エラーメッセージで失敗します。このエラーは、ターゲットプロジェクトのコンテキストでは、$CI_COMMIT_REF_NAMEが存在しないブランチ名と評価されるために発生します。
正しいコンテキストを取得するには、$CI_PROJECT_PATHの代わりに$CI_MERGE_REQUEST_SOURCE_PROJECT_PATHを使用します。この変数は、マージリクエストパイプラインでのみ使用できます。
たとえば、プロジェクトフォークとブランチパイプラインで開始されたマージリクエストパイプラインの両方をサポートする設定では、includeディレクティブとrules:ifの両方を組み合わせる必要があります:
include: # Execute individual project's configuration (if project contains .gitlab-ci.yml)
- project: '$CI_MERGE_REQUEST_SOURCE_PROJECT_PATH'
file: '$CI_CONFIG_PATH'
ref: '$CI_COMMIT_REF_NAME'
rules:
- if: $CI_PIPELINE_SOURCE == 'merge_request_event'
- project: '$CI_PROJECT_PATH'
file: '$CI_CONFIG_PATH'
ref: '$CI_COMMIT_REF_NAME'
rules:
- if: $CI_PIPELINE_SOURCE != 'merge_request_event'設定ファイルがないプロジェクトのコンプライアンスパイプライン
設定例は、すべてのプロジェクトにパイプライン設定ファイル（デフォルトでは.gitlab-ci.yml）が含まれていることを前提としています。ただし、設定ファイルがないプロジェクト（したがって、デフォルトではパイプラインがない）では、include:projectで指定されたファイルが必要なため、コンプライアンスパイプラインは失敗します。
ターゲットプロジェクトに存在する場合にのみ設定ファイルを含めるには、rules:exists:projectを使用します:
include: # Execute individual project's configuration
- project: '$CI_PROJECT_PATH'
file: '$CI_CONFIG_PATH'
ref: '$CI_COMMIT_SHA'
rules:
- exists:
paths:
- '$CI_CONFIG_PATH'
project: '$CI_PROJECT_PATH'
ref: '$CI_COMMIT_SHA'この例では、設定ファイルは、exists:project: $CI_PROJECT_PATH'のプロジェクトの特定のrefに存在する場合にのみ含まれます。
exists:projectがコンプライアンスパイプライン設定で指定されていない場合、includeが定義されているプロジェクト内のファイルを検索します。コンプライアンスパイプラインでは、前の例のincludeは、パイプラインを実行しているプロジェクトではなく、コンプライアンスパイプライン設定ファイルをホストしているプロジェクトで定義されています。
コンプライアンスジョブが常に実行されるようにする
コンプライアンスパイプラインはGitLab CI/CDを使用して、必要なあらゆる種類のコンプライアンスジョブを定義するための驚くほど優れた柔軟性を提供します。目標に応じて、これらのジョブは次のように設定できます:
- ユーザーが変更。
- 変更不可。
一般に、コンプライアンスジョブの値が次の場合は、:
- 設定されている場合、プロジェクトレベルの設定によって変更またはオーバーライドすることはできません。
- 設定されていない場合、プロジェクトレベルの設定を設定できます。
どちらも、ユースケースによっては必要かどうかが異なる場合があります。
これらのジョブが常に定義したとおりに正確に実行され、ダウンストリームのプロジェクトレベルのパイプライン設定がそれらを変更できないようにするためのベストプラクティスを次に示します:
- 各コンプライアンスジョブに
rules:when:alwaysブロックを追加します。これにより、変更できなくなり、常に実行されるようになります。 - ジョブが参照する変数を明示的に設定します。これは:
- プロジェクトレベルのパイプライン設定がそれらを設定せず、その動作を変更しないようにします。たとえば、設定例の
before_scriptおよびafter_script設定を参照してください。 - ジョブのロジックを駆動するジョブをすべて含めます。
- プロジェクトレベルのパイプライン設定がそれらを設定せず、その動作を変更しないようにします。たとえば、設定例の
- ジョブの実行対象となるコンテナイメージを明示的に設定します。これにより、スクリプトの手順が正しい環境で実行されるようになります。
- 関連するGitLab事前定義済みジョブキーワードを明示的に設定します。これにより、ジョブが意図した設定を使用し、プロジェクトレベルのパイプラインによってオーバーライドされないようになります。
トラブルシューティング
コンプライアンスジョブは、ターゲットリポジトリによって上書きする
コンプライアンスパイプライン設定でextendsステートメントを使用すると、コンプライアンスジョブはターゲットリポジトリジョブによって上書きされます。例えば、次の.compliance-gitlab-ci.ymlの設定を使用できます:
"compliance job":
extends:
- .compliance_template
stage: build
.compliance_template:
script:
- echo "take compliance action"次の.gitlab-ci.yml設定も可能です:
"compliance job":
stage: test
script:
- echo "overwriting compliance action"この設定により、ターゲットリポジトリパイプラインがコンプライアンスパイプラインを上書きし、次のメッセージが表示されます: overwriting compliance action
コンプライアンスジョブの上書きを回避するには、コンプライアンスパイプライン設定でextendsキーワードを使用しないでください。例えば、次の.compliance-gitlab-ci.ymlの設定を使用できます:
"compliance job":
stage: build
script:
- echo "take compliance action"次の.gitlab-ci.yml設定も可能です:
"compliance job":
stage: test
script:
- echo "overwriting compliance action"この設定では、コンプライアンスパイプラインは上書きされず、次のメッセージが表示されます: take compliance action
事前に入力された変数が表示されない
既知の問題により、GitLab 15.3以降のコンプライアンスパイプラインは、事前に入力された変数がパイプラインを手動で開始するときに表示されないようにする可能性があります。
この問題を回避策するには、個々のプロジェクトの設定を実行するinclude:ステートメントで、ref: '$CI_COMMIT_REF_NAME'の代わりにref: '$CI_COMMIT_SHA'を使用します。
設定例がこの変更で更新されました:
include:
- project: '$CI_PROJECT_PATH'
file: '$CI_CONFIG_PATH'
ref: '$CI_COMMIT_SHA'エラー: Job names must be unique
コンプライアンスパイプラインを設定するために、設定例では、include.projectを使用して個々のプロジェクト設定を含めることを推奨しています。
この設定により、プロジェクトパイプラインの実行時にエラーが発生する可能性があります：Pipeline execution policy error: Job names must be unique。このエラーは、パイプライン実行ポリシーにプロジェクトの.gitlab-ci.ymlが含まれており、ジョブがパイプラインですでに宣言されている場合に、ジョブを挿入しようとするために発生します。
このエラーを解決するには、パイプライン実行ポリシーにリンクされている個別のYAMLファイルからinclude.projectを削除します。