GitLab Secrets Managerでシークレットをコードと同じ統制下に

認証情報の多くは、エンジニアのローカル開発環境から始まります。そして、パイプラインを止めないためにスコープを設定しないCI/CD変数へとコピーされていきます。そこに置かれるのは、スコープ付きシークレットへの参照ではなく生の値そのもの。結果として署名キーは、侵害されているかどうかに関係なく、パイプライン内のすべてのジョブから届く状態になります。

シークレット専用の保管庫を別に立てれば、露出する範囲は確かに狭まります。ただし、プロジェクトのメンバー構成、保護ブランチ、本番環境に変更を加えるたびに、その内容を保管庫側にも反映させ続けなければなりません。反映が追いつかなくなれば、パイプラインが止まるか、エージェントのサービスアカウントが、すでに不要になったアクセス権を持ち続けることになります。

GitLab Secrets Managerは、2つ目の権限モデルを増やすことなく認証情報の守りを固めます。GitLab 19.5で一般提供（GA）を開始し、GitLab.comとGitLab Self-ManagedのPremiumおよびUltimateでご利用いただけます。GitLab Dedicatedへの対応も近日中に予定。基盤となるOpenBaoが、ビルド時とランタイムの認証情報を、コードとまったく同じ権限と監査証跡のもとで預かります。プラットフォームチームはデベロッパーがセルフサービスでシークレットを扱える状態を用意でき、セキュリティチームの側では、認証情報がそれを使うジョブだけにスコープを絞られたうえ、CI/CDからの読み取りに毎回パイプラインIDとジョブIDが残ります。

「GitLab Secrets Managerのおかげで、保管庫をいくつも立てたり、別々の連携口を維持したりすることなく、CI/CD、Kubernetes、Infrastructure as Codeをまたいでシークレットを一元管理できています。ある認証情報に手が届くユーザーとパイプラインを絞り込めるので、ソフトウェアサプライチェーンの守りも固くなりました」 - OneTrust ソフトウェアアーキテクト Jeremy Nauta氏

ビルド時のシークレットをジョブ単位で絞り込む仕組み

エージェントは、誰も想定していなかった動き方をすることがあります。だからこそセキュリティチームは、ジョブの中のエージェントが手の届く認証情報をすべて使うものとして、あらゆるジョブを見ておく必要があります。Secrets Managerが手がかりにするのは、GitLabがすでに持っているジョブの文脈。そのジョブが属するプロジェクト、実行されるブランチ、そのブランチが保護されているかどうか、そして対象とする環境です。これらをもとに、エージェントの手が届く範囲を狭めていきます。

デベロッパーは、ジョブに必要なシークレットを.gitlab-ci.ymlのsecrets:キーワードで宣言します。GitLabが値を渡すのは、宣言があり、なおかつスコープの条件に合致するジョブだけ。スコープの条件はブランチと環境でワイルドカードが使えるうえ、条件同士を重ねることもできます。たとえば、保護ブランチであることとproduction/*環境であることの両方を満たしたジョブにだけ認証情報を渡す、といったルールも1つで書けます。

ジョブの中では、GitLabが値を一時ファイルに書き出し、見えるようにするのはそのパスだけです。サブプロセスやクラッシュダンプ、テレメトリーに値がこぼれる余地を減らすためです。ジョブログでは値をマスクし、ジョブが終われば破棄。CI/CD変数と違い、シークレットがプロジェクトの設定画面から読み取れることはありません。 OpenBaoはシークレットをAES-256-GCMで暗号化したまま保存するため、データベースのコピーが人手に渡っても、そこにあるのは暗号文だけ。ジョブは、自身のIDに紐付いた短命のトークンでOpenBaoから直接値を取り出すので、平文のシークレットがGitLabアプリケーション側に残ることもありません。

Secrets Managerの始め方は、こちらの動画でご覧ください。

流出した認証情報を失効させ、経路をたどる

npmパッケージのaxiosが侵害されたとき、SANSのアドバイザリは、影響を受けたシステム上の環境変数はすべて盗まれたものとみなすよう呼びかけ、調査の範囲をCI/CDのRunnerやビルド基盤にまで広げるよう促しました。対応にあたったチームは、影響を受けたジョブごとにどの認証情報を読めたのか、どうすればアクセスを断てるのか、どの実行がそれを読んだのかを、一つひとつ突き止めていくほかありませんでした。

Secrets Managerがあれば、ジョブが汚染された依存関係を実行しても、露出はそのジョブが宣言し、読み取りを認可されていたシークレットの範囲で止まります。あとの手当てはシンプルです。流出した認証情報を失効させて差し替え、Secrets Manager上の値を更新し、該当するジョブだけを監査する。その間もほかのパイプラインは動き続けます。シークレットを作成するときには、ローテーションのリマインダーを設定するよう促されるほか、手動のローテーションを必要としない動的な認証情報も近日中に提供予定です。

GitLabは、シークレットの作成・読み取り・更新・削除をすべて監査イベントとして送信先にストリーミングし、変更の内容を監査証跡に記録します。パイプラインからの読み取りに付くのは、パイプラインIDとジョブID。そこからコミット、実行をトリガーしたユーザー、マージリクエストがあればそのマージリクエストまで、一本の線でたどれます。CIシステム、シークレット保管庫、IDプロバイダーのログを突き合わせる手間も不要。インシデント対応担当者も監査担当者も、1件の読み取りからその背後にある変更へ直接行き着けます。監査イベントにシークレットの値が含まれることはありません。

コードを統制する権限で、シークレットも統制する

エージェントが担う仕事が増えれば、認証情報を必要とするパイプラインやサービスアカウントの依頼も、プラットフォームチームに次々と集まってきます。依頼がさばききれずに滞ると、現場は広めの権限付与と使い回しのシークレットに流れがちです。

Secrets Managerが分離の境界に使うのは、GitLabのネームスペース。プロジェクトは上位グループで定義されたシークレットを引き継ぐので、共有の認証情報は一度定義すれば足ります。権限の付与も、コードを統制しているのと同じメンバーシップモデルのまま。オーナーが、特定のユーザーやデフォルトロールに読み取り・書き込み・削除を割り当てます。プロジェクトからメンバーやエージェントのサービスアカウントを外せば、そのIDからプロジェクトのシークレットへのアクセスもその場で途切れます。

デベロッパーは、すでに持っているプロジェクトのアクセス権でシークレットを参照します。参照が壊れたときも、直す場所はコードと同じマージリクエストの中。別のリポジトリも、別の承認者も、アクセス申請のチケットも要りません。統制された認証情報が1行で手に入るなら、スコープの広すぎるCI/CD変数やローカルファイル、リポジトリにシークレットが紛れ込む場面も自然と減っていきます。

パイプラインとランタイムのワークロードを1つのストアで

Kubernetes、Terraform、各種スクリプトには、それぞれ別のシークレットストアがあてがわれがちです。アクセスの考え方もログも、ばらばらのまま。Secrets Managerなら、ランタイムのツールにもパイプラインと同じストアから、同じ権限と監査証跡のもとでシークレットを届けられます。

• Kubernetes（External Secrets Operator経由）。ESOが一定の間隔でシークレットを取り直し、Kubernetes Secretをその場で更新するため、ローテーションした値はパイプラインを動かさなくてもクラスターに届きます。
• TerraformとOpenTofu。planやapplyの時点でシークレットをデータソースとして読み込むので、認証情報を.tfvarsファイルやCI/CD変数に置かずに済みます。
• OpenBaoとVaultのCLI（Vault互換API経由）。既存のスクリプトはそのままに、向き先をSecrets Managerに変えるだけで動きます。
• その他のランタイムツール（Secrets Manager API経由）。

ランタイムのツールは、サービスアカウントかアクセストークンで認証します。そのIDに求められるのは、プロジェクトのメンバーシップと、対象のシークレットに対する明示的な読み取り権限。条件がそろうと、GitLabは有効期間5分の別のトークンを発行し、ツールはそれを使ってシークレットを取り出します。

GitLabのサプライチェーン統制のなかでのSecrets Managerの位置づけ

GitLabの統制されたソフトウェアファクトリーは、コード、パイプライン、パッケージ、シークレットを1つのプラットフォームの上でつなぎ、1つのIDモデルと、変更が本番環境に届くまでの一続きの記録をもたらします。パイプラインに入るパッケージをDependency Firewallが見極め、そのパイプラインの手が届く認証情報をSecrets Managerが絞り込み、出荷するものをArtifact Centralが統制します。

エージェントが自律性を段階的に獲得していくためのGitLabのフレームワーク、GitLab Security Standard。Secrets Managerはその5つのステージのうち、2つを支えます。*認可（Authorize）*では、各ジョブを、そのIDとスコープが許すシークレットだけに結び付け、*対応（Respond）*では、すべてのCRUDイベントをストリーミングします。

シークレットプッシュ保護は、認証情報を含むコミットをリポジトリに届く前で止め、シークレット検出は、すでにコードや履歴に入り込んでいるものを探し出します。スキャン結果のトリアージを担うのはGitLab Duo Agent Platform。偽陽性の可能性が高いものにフラグが立つため、チームは本当の流出だけを失効・ローテーション・監査の対象にできます。

HashiCorp Vault、AWS Secrets Manager、Azure Key Vault、Google Cloud Secret Managerとの既存のインテグレーションは、Secrets Managerと並行してこれまでどおり動きます。移行のペースは、ご自身で決めていただけます。

今すぐ始める

GitLab Secrets Managerは、PremiumおよびUltimate向けの有償アドオン。課金はGitLabクレジットを通じて行われ、保管するシークレット1件につき月1クレジット、読み取り操作2,500回につき1クレジットという料金体系です。エアギャップ環境向けには、エンタープライズライセンス契約もご用意しています。

• GitLab.comでは、トップレベルグループのオーナーがGitLab Secrets Managerを無料でお試しいただけます。期間は30日間、または評価用クレジット500まで。どちらか早いほうで終了します。トップレベルグループを開き、安全 > Secrets Managerから30日間のトライアルを開始を選んでください。
• GitLab Self-Managedでは、管理者によるSecrets Managerのインストールと有効化が必要です。その際は、ドキュメントに記載のサイジングと高可用性のガイダンスに従ってください。
• GitLab Dedicatedへの対応は近日中に提供予定です。

まず移行すべき認証情報を見つけるには、CI/CD変数向けのシークレット監査ツールをお試しください。認証情報を抱えている可能性の高い変数にフラグが立ちます。CI/CD変数の移行ワークフローは現在開発中です。

ご意見やフィードバックは、Secrets Managerのフィードバックイシューまでお寄せください。