- プロジェクトへのコンプライアンス フレームワークの追加
- デフォルトのコンプライアンスフレームワーク
- コンプライアンス パイプライン
- コンプライアンスジョブが常に実行されるようにします。
- GitLab 14.7以前では親パイプラインと子パイプラインを避けてください。
- トラブルシューティング
コンプライアンスの枠組み
プロジェクトに特定のコンプライアンス要件があることや、追加の監視が必要であることを示すラベルとして、コンプライアンスフレームワークを作成することができます。このラベルは、オプションで適用されるプロジェクトにコンプライアンスパイプラインの設定を強制することができます。
コンプライアンス フレームワークは、トップレベルのグループに作成されます。グループのオーナーは、コンプライアンス フレームワークを作成、編集、削除できます：
- 左のサイドバーで、Search（検索）を選択するか、Go to（移動）を選択してグループを探します。
- 設定>一般を選択します。
- Compliance frameworks] セクションを展開します。
- コンプライアンス フレームワークを作成、編集、または削除します。
サブグループとプロジェクトは、その最上位グループに作成されたすべてのコンプライアンス フレームワークにアクセスできます。ただし、サブグループまたはプロジェクト レベルでコンプライアンス フレームワークを作成、編集、または削除することはできません。プロジェクト オーナーは、プロジェクトに適用するフレームワークを選択できます。
プロジェクトへのコンプライアンス フレームワークの追加
前提条件
- プロジェクトが所属するグループがコンプライアンスの枠組みを持っていること。
プロジェクトにコンプライアンス フレームワークを割り当てるには
- 左のサイドバーで「検索」または「移動」を選択してあなたのプロジェクトを検索します。
- 設定>一般を選択します。
- コンプライアンスフレームワークを展開します。
- コンプライアンス フレームワークを選択します。
- 変更を保存を選択します。
GraphQL API
GitLab 14.2で導入されました。
GraphQL APIを使ってプロジェクトにコンプライアンスフレームワークを追加することができます。
GraphQLでサブグループにコンプライアンスフレームワークを作成する場合、ユーザーが正しい権限を持っていれば、フレームワークはルートの先祖に作成されます。GitLab UI はこの動作を阻止するために読み取り専用のビューを表示します。
デフォルトのコンプライアンスフレームワーク
GitLab 15.6で導入されました。
グループオーナーはデフォルトのコンプライアンスフレームワークを設定することができます。デフォルトのフレームワークは、そのグループで作成されるすべての新規プロジェクトとインポートプロジェクトに適用されます。既存のプロジェクトに適用されるフレームワークには影響しません。デフォルトのフレームワークは削除できません。
デフォルトに設定されたコンプライアンス フレームワークには、デフォルトのラベルがあります。
デフォルトとして設定および削除
GitLab 15.7 で導入されました。
グループオーナーは、コンプライアンスフレームワークをデフォルトとして設定することができます（設定を削除することもできます）：
- 左のサイドバーで、Search（検索）を選択するか、Go to（移動）を選択してグループを探します。
- 設定] > [全般]を選択します。
- コンプライアンス フレームワーク] セクションを展開し、デフォルトとして設定 (または削除) するコンプライアンス フレームワークを見つけます。
- コンプライアンス フレームワークの垂直省略記号({ellipsis_v}) を選択し、[デフォルトに設定する (またはデフォルトを削除する)] を選択します。
デフォルトのコンプライアンス フレームワークを設定するための GraphQL 変異の例
新しいコンプライアンスフレームワークを作成し、それをグループのデフォルトフレームワークとして設定します。
mutation {
createComplianceFramework(
input: {params: {name: "SOX", description: "Sarbanes-Oxley Act", color: "#87CEEB", default: true}, namespacePath: "gitlab-org"}
) {
framework {
id
name
default
description
color
pipelineConfigurationFullPath
}
errors
}
}
既存のコンプライアンス フレームワークをグループのデフォルト フレームワークとして設定します。
mutation {
updateComplianceFramework(
input: {id: "gid://gitlab/ComplianceManagement::Framework/<id>", params: {default: true}}
) {
complianceFramework {
id
name
default
description
color
pipelineConfigurationFullPath
}
}
}
コンプライアンス パイプライン
グループオーナーは、他のプロジェクトとは別のプロジェクトでコンプライアンスパイプラインを設定することができます。デフォルトでは、ラベル付きプロジェクトのパイプライン設定(例えば、.gitlab-ci.yml)の代わりに、コンプライアンスパイプライン設定(例えば、.compliance-gitlab-ci.yml)が実行されます。
ただし、コンプライアンス・パイプライン設定は、ラベル付けされたプロジェクトの.gitlab-ci.yml ファイルを参照することができます：
- コンプライアンスパイプラインは、ラベル付けされたプロジェクトパイプラインのジョブも実行できます。これにより、パイプライン設定を一元管理できます。
- コンプライアンスパイプラインで定義されたジョブや変数は、ラベル付けされたプロジェクトの
.gitlab-ci.ymlファイルの変数によって変更されることはありません。
詳細については
- ラベル付けされたプロジェクトパイプライン設定からジョブを実行するコンプライアンスパイプラインの設定については、設定例を参照してください。
- コンプライアンス パイプラインの作成” を参照してください。
ラベル付きプロジェクトへの影響
ユーザーは、コンプライアンスパイプラインが設定されていることを知る方法がないため、自分のパイプラインがまったく実行されていなかったり、自分で定義していないジョブが含まれていたりすることに戸惑う可能性があります。
ラベル付けされたプロジェクトでパイプラインを作成する場合、コンプライアンスパイプラインが設定されていることを示す表示はありません。プロジェクト レベルでの唯一の目印はコンプライアンス フレームワークのラベルですが、このラベルには、フレームワークにコンプライアンス パイプラインが設定されているかどうかは記載されていません。
そのため、プロジェクト ユーザーとコンプライアンス パイプラインの設定についてコミュニケーションを取り、不確実性と混乱を減らしてください。
コンプライアンス パイプラインの設定
コンプライアンス パイプラインを設定します：
- 左のサイドバーで、Search（検索）を選択するか、Go to（移動）を選択してグループを探します。
- 設定>一般を選択します。
- Compliance frameworks] セクションを展開します。
-
コンプライアンス パイプライン設定 (オプション)] で、コンプライアンス フレームワーク設定へのパスを追加します。
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 be the hardcoded path to the project that hosts 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 設定は、コンプライアンス・パイプラインがホスト・プロジェクト自体で実行できる必要がある場合に、循環インクルードを回避します。コンプライアンス・パイプラインがラベル付きプロジェクトでのみ実行される場合は、このキーワードを省略できます。
外部でホストされるコンプライアンスパイプラインとカスタムパイプライン設定
上記の例では、すべてのプロジェクトが同じプロジェクト内でパイプライン設定をホストしていると仮定しています。プロジェクトの外部でホストされている設定を使用しているプロジェクトがある場合：
-
コンプライアンスパイプライン設定例の
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/CDを使ったコンプライアンスパイプラインでは、驚くほど柔軟にコンプライアンスジョブを定義することができます。目的に応じて、これらのジョブを設定することができます：
- ユーザーによる変更。
- 変更不可。
一般的に、コンプライアンス・ジョブにおける値：
- 設定されている場合、プロジェクトレベルの設定によって変更または上書きすることはできません。
- が設定されていない場合は、プロジェクトレベルの設定が設定されている可能性があります。
使用するケースによって、どちらでもよいかもしれません。
以下は、これらのジョブが常に定義したとおりに実行され、ダウンストリームのプロジェクトレベルのパイプライン設定がそれらを変更できないようにするためのいくつかのベストプラクティスです：
-
rules:when:alwaysブロック をそれぞれのコンプライアンスジョブに追加します。これにより、ジョブが変更不可能で、常に実行されるようになります。 - ジョブが参照する変数を明示的に設定します。これは
- プロジェクトレベルのパイプライン設定によって変数が設定され、動作が変更されないようにします。
- ジョブのロジックを駆動するすべてのジョブを含みます。
- ジョブを実行するコンテナイメージを明示的に設定します。これにより、スクリプトステップが正しい環境で実行されるようになります。
- 関連するGitLabの定義済みジョブキーワードを明示的に設定します。これにより、ジョブが意図した設定を使用し、プロジェクトレベルのパイプラインによって上書きされないようにします。
GitLab 14.7以前では親パイプラインと子パイプラインを避けてください。
コンプライアンス・パイプラインは、ラベル付きプロジェクト内の_すべての_パイプラインの実行時に開始されます。つまり、ラベル付けされたプロジェクト内のパイプラインが子パイプラインをトリガーする場合、コンプライアンスパイプラインが最初に実行されます。これにより、子パイプラインではなく親パイプラインがトリガーされることがあります。
したがって、コンプライアンス・フレームワークを使用するプロジェクトでは、親子パイプラインを次のように置き換える必要があります：
この方法では、コンプライアンス パイプラインが親パイプラインを再スタートしないようにします。
トラブルシューティング
コンプライアンスジョブがターゲットリポジトリで上書きされます。
コンプライアンスパイプライン設定で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'