更新日:2025年11月12日
8分で読めます
このガイドでは、明示的な宣言、型安全性、検証の実装など、パイプラインのカスタマイズに関するより強力な制御について説明します。

パイプライン変数は、GitLab CI/CDパイプラインを実行時にカスタマイズする便利な方法として長く活用されてきました。しかし、CI/CDセキュリティのベストプラクティスが進化するにつれ、パイプラインのカスタマイズに関してより強力な制御が必要であることが明らかになりました。制限のないパイプライン変数では、パイプライントリガー権限を持つユーザーが、検証や型のチェックなしに値を上書きできてしまいます。
セキュリティ上の考慮事項に加えて、パイプライン変数には適切なドキュメントと明示的な宣言が欠けているため、どのような入力が想定され、パイプライン全体でどのように使用されるかを理解することが困難です。これにより、メンテナンスの課題が生じ、CI/CDプロセスに対する適切なガバナンスの確立が難しくなります。
パイプライン変数に依存する代わりに、GitLabのパイプライン入力機能の使用を強く推奨します。パイプライン入力には次の利点があります:
明示的な宣言: 入力は.gitlab-ci.ymlで明示的に宣言する必要があり、自己文書化されます。
型安全性: 異なる入力型(文字列、ブール値、数値、配列)をサポートします。
組み込みの検証: 入力値の自動検証が行われます。
セキュリティの向上: 変数インジェクション攻撃のリスクがなく、宣言された入力のみが外部から渡されます。
spec:
inputs:
deployment_env:
description: "ターゲットデプロイメント環境"
type: string
options: ["staging", "production"]
default: "staging"
enable_tests:
description: "テストスイートを実行"
type: boolean
default: true
test:
script:
- echo "テストを実行中"
rules:
- if: $[[ inputs.enable_tests ]] == true
deploy:
script:
- echo "$[[ inputs.deployment_env ]]へデプロイ中"
CI/CD入力が検証付きで型安全なパラメータ渡しを実現する方法については、このチュートリアルをご覧ください。
パイプライン入力への移行を効果的に進め、パイプライン変数からの移行を促進するには、「パイプライン変数が使用できる最小ロール」設定を構成する必要があります。この設定により、パイプラインをトリガーする際にどのロールがパイプライン変数を使用できるかを細かく制御できます。
プロジェクトレベル: プロジェクトの [設定] > [CI/CD] > [変数] > [パイプライン変数が使用できる最小ロール] の順に移動して、設定を構成します。
利用可能なオプション:
誰にも許可しない(no_one_allowed) - 推奨される最も安全なオプションです。すべての変数の上書きを防ぎます。
デベロッパー(developer) - デベロッパー以上のロールが変数を上書きできます。
メンテナー(maintainer) - メンテナーロール以上が必要です。
オーナー(owner) - プロジェクトオーナーのみが変数を上書きできます。
グループレベル: グループメンテナーは、[設定] > [CI/CD] > [変数] > [パイプライン変数を使えるデフォルトロール]の順に移動して、グループ内のすべての新規プロジェクトに適用される安全なデフォルト値を設定できます。これにより組織全体で一貫したセキュリティポリシーを確保できます。ここでも、デフォルト値として誰にも許可しないを使用することを推奨します。これにより、このグループ内の新規プロジェクトは安全なデフォルト設定で作成されます。なお、プロジェクトオーナーは引き続きこの設定を変更できます。
パイプライン変数が完全に制限されている場合(「誰にも許可しない」の場合)、事前入力された変数は「新しいパイプラインUI」フォームに表示されません。
組織内には、パイプラインをトリガーする際に一度も使用したことがないにもかかわらず、パイプライン変数がデフォルトで有効になっているプロジェクトが存在する可能性があります。これらのプロジェクトは、中断のリスクなしにより安全な設定に移行できます。GitLabは、グループ設定を通じて移行機能を提供しています:
[設定] > [CI/CD] > [変数] の順に移動します。
パイプライン変数を使用していないプロジェクトで、パイプライン変数を無効にするで、マイグレーションの開始を選択します。
この移行は、過去に使用したことがないすべてのプロジェクトのプロジェクト設定を通じて、パイプライン変数を安全に無効にするバックグラウンドジョブです。
特定されたパイプライン変数ごとに、対応するパイプライン入力を作成します。
変更前(パイプライン変数を使用)
variables:
DEPLOY_ENV:
description: "デプロイメント環境"
value: "staging"
ENABLE_CACHE:
description: "デプロイメントキャッシュを有効化"
value: "true"
VERSION:
description: "アプリケーションバージョン"
value: "1.0.0"
deploy:
script:
- echo "$DEPLOY_ENVへバージョン$VERSIONをデプロイ中"
- |
if [ "$ENABLE_CACHE" = "true" ]; then
echo "キャッシュが有効です"
fi
変更後(パイプライン入力を使用)
spec:
inputs:
deploy_env:
description: "デプロイメント環境"
type: string
default: "staging"
options: ["dev", "staging", "production"]
enable_cache:
description: "デプロイメントキャッシュを有効化"
type: boolean
default: true
version:
description: "アプリケーションバージョン"
type: string
default: "1.0.0"
regex: '^[0-9]+\.[0-9]+\.[0-9]+$'
deploy:
script:
- echo "$[[ inputs.deploy_env ]]へバージョン$[[ inputs.version ]]をデプロイ中"
- |
if [ "$[[ inputs.enable_cache ]]" = "true" ]; then
echo "キャッシュが有効です"
fi
triggerキーワードでトリガージョブを使用している場合は、ジョブレベルのvariablesを定義していないこと、またはトップレベルのvariables、extends、includeからの変数の継承を無効にしていないことを確認してください。変数が暗黙的にダウンストリームにパイプライン変数として渡される可能性があるためです。ダウンストリームプロジェクトでパイプライン変数が制限されている場合、パイプラインの作成は失敗します。
パイプライン変数の代わりに、パイプライン入力を使用するようにCI構成を更新することを検討してください。
variables:
FOO: bar
deploy-staging:
inherit:
variables: false # そうしないとFOOがダウンストリームにパイプライン変数として送信されます
trigger:
project: myorg/deployer
inputs:
deployment_env: staging
enable_tests: true
パイプライン変数からパイプライン入力への移行は、変数インジェクションからCI/CDインフラを保護するセキュリティ強化であり、同時により優れたドキュメント、型安全性、検証を提供します。これらの制限を実装し、パイプライン入力を採用することで、セキュリティを向上させるだけでなく、パイプラインをよりメンテナンスしやすく、自己文書化され、耐障害性の高いものにすることができます。
移行には初期の労力が必要ですが、長期的なメリットは移行コストをはるかに上回ります。まず、新規プロジェクトのグループレベルでパイプライン変数を制限ることから始め、次に上記の段階的なアプローチを使用して既存のパイプラインを体系的に移行してください。
セキュリティの強化は、終わりのない継続的なプロセスです。パイプライン入力は、保護されたブランチ、ジョブトークン許可リスト、コンテナレジストリ保護など、他のGitLabセキュリティ機能を補完し、より安全なCI/CD環境を構築するための重要なステップです。
パイプライン入力を始めるには、GitLab Ultimateの無料トライアルに今すぐ登録してください。