【ITニュース解説】Passing Dynamic Environment Variables Between GitLab CI Matrix Jobs: AWS OIDC Example

CI/CD、つまり継続的インテグレーションと継続的デリバリーは、ソフトウェアを開発し、ユーザーに届けるまでの一連の流れを自動化する仕組みだ。この自動化の仕組みをパイプラインと呼び、GitLab CI/CDのようなツールを使うことで、コードの変更からテスト、デプロイまでを効率的に実行できる。特に、複数の環境、例えば開発環境、ステージング環境、本番環境などへ同時に同じアプリケーションをデプロイしたい場合、GitLab CIのparallel:matrixという機能が非常に強力だ。これは、同じ設定の処理（ジョブ）を、環境名などのパラメータだけを変えて並列に実行してくれる機能であり、作業時間を大幅に短縮できる。しかし、この便利な機能には一つ課題がある。それは、パイプラインの実行中に動的に生成された情報を、後続のジョブにどうやって渡すかという問題だ。例えば、デプロイの直前にセキュリティを確保するために発行される一時的なパスワードや認証キーなどがこれにあたる。このような情報はジョブが実行されるまで確定しないため、あらかじめ変数として設定しておくことができない。さらに、並列実行されている各環境（例えばalpha環境とbeta環境）でそれぞれ異なる一時キーが生成された場合、alpha用のキーを後続のalpha用デプロイジョブに、beta用のキーを後続のbeta用デプロイジョブに、それぞれ正しく受け渡す必要がある。この情報の受け渡しを確実に行うことが、複雑なパイプラインを構築する上での重要な課題となる。

この課題を解決する鍵となるのが、GitLab CIの「アーティファクト」という機能だ。アーティファクトとは、あるジョブが完了した際に生成されるファイルやディレクトリを指し、パイプライン内の後続ジョブで利用するために一時的に保存しておくことができる仕組みである。この仕組みを利用することで、動的に生成された情報をジョブ間で安全に受け渡すことが可能になる。具体的な手法は、まず先行するジョブで動的な情報を生成し、その情報をファイルに書き出す。このとき、ファイル名にparallel:matrixで定義した環境名（例えばalphaやbeta）を含めることで、どの環境向けの情報なのかを明確に区別できるようにする。例えば、credentials_alpha.envやcredentials_beta.envといったファイル名にする。そして、これらのファイルをアーティファクトとして保存するよう設定する。次に、後続のジョブでは、アーティファクトとして保存されたファイル群の中から、自身の環境名に一致するファイルを探し出して読み込む。これにより、alpha環境用のデプロイジョブはcredentials_alpha.envの内容を、beta環境用のデプロイジョブはcredentials_beta.envの内容を確実に利用でき、情報の混同を防ぐことができる。この「環境ごとに固有のファイル名で情報を保存し、アーティファクトで共有する」というアプローチが、動的な変数を並列ジョブ間で受け渡すための標準的かつ堅牢な解決策となる。

この手法の具体的な応用例として、クラウドサービスであるAWSへのデプロイが挙げられる。AWSのようなクラウド環境へ安全にデプロイを行う際、IDやパスワードのような固定の認証情報をCI/CDツールに直接保存するのはセキュリティ上のリスクが高い。そこで、OIDC（OpenID Connect）という仕組みを利用した認証が推奨される。これは、GitLabとAWSがお互いを信頼し、パスワードを使わずに安全な通信を行うための標準的な技術だ。具体的には、GitLab CIのジョブが実行されると、GitLabがそのジョブ専用の一時的な証明書（OIDCトークン）を発行する。ジョブはこのトークンをAWSに提示し、AWSはトークンが信頼できるGitLabから発行されたものであることを確認すると、そのジョブだけが一定時間使える一時的な認証情報（アクセスキーなど）を発行する。この一連の流れにより、永続的な認証情報をコードや変数に保存することなく、安全にAWSのリソースを操作できるようになる。このOIDCで取得した一時的な認証情報こそが、まさに動的に生成される変数だ。これをparallel:matrixで実行される各環境のデプロイジョブに渡すために、アーティファクトを利用する。まずget-aws-credentialsというジョブをalphaとbetaの各環境で並列実行する。それぞれのジョブはOIDCを使ってAWSから各環境専用の一時認証情報を取得し、alpha用は.aws.alpha.env、beta用は.aws.beta.envというファイルにその内容を書き出す。これらのファイルがアーティファクトとしてパイプラインに保存される。その後、deployジョブが同様に並列で実行され、alpha用のジョブは.aws.alpha.envファイルを、beta用のジョブは.aws.beta.envファイルをアーティファクトから読み込む。そして、ファイルに書かれた認証情報を環境変数として設定することで、AWSへの接続を確立し、デプロイ処理を実行する。このように、環境ごとに生成された動的な認証情報が、アーティファクトを介して後続の対応するジョブへと正確に引き継がれる。

このように一時的な認証情報のような機密データを扱う際には、セキュリティへの配慮が不可欠だ。まず、アーティファクトの有効期限を適切に設定することが重要である。認証情報が含まれるファイルがGitLabのストレージに長期間残らないよう、例えばexpire_in: 1 hourのように有効期限を1時間程度に設定し、パイプライン完了後には速やかに削除されるようにするべきだ。また、AWS側で設定するIAMロール（権限の集合体）は、最小権限の原則に従う必要がある。これは、デプロイに必要な操作（ファイルのアップロードなど）だけを許可し、それ以外の権限は与えないという考え方だ。これにより、万が一認証情報が漏洩した場合でも、被害を最小限に抑えることができる。さらに、AWSのIAMロールが信頼する対象を厳密に設定することも大切だ。GitLabの特定のプロジェクトの、特定のブランチ（例えばmainブランチ）からのリクエストのみを許可するように信頼ポリシーを構成することで、意図しない場所からAWSリソースが操作されるリスクを防ぐ。ファイルに認証情報を書き出す本手法は、認証情報がGitLabの実行ログに誤って表示されるリスクを低減する効果もあるが、これらのセキュリティ設定を総合的に行うことで、CI/CDパイプライン全体の安全性が確保される。

この「動的情報をファイル化し、アーティファクトで共有する」というテクニックは、AWSの一時的な認証情報を渡すためだけのものではない。データベースの接続文字列や外部サービスのAPIトークンなど、環境ごとに異なり、かつ実行時に動的に生成されるあらゆる種類の情報を受け渡す際に広く応用できる。例えば、テスト用のデータベースをジョブの開始時に動的に作成し、その接続情報を後続のテスト実行ジョブに渡すといったケースでも活用可能だ。重要なのは、環境を識別する変数を使ってファイル名を一意に決定し、アーティファクトを中継点として利用するという考え方である。このパターンを理解することで、複数の環境やテナントに対応した、柔軟で安全性の高いCI/CDパイプラインを構築する能力が大きく向上するだろう。