GitLab Secrets ManagerでCI/CD認証情報を管理

認証情報の漏洩の多くは、認証情報を必要としているのに適切な保存場所がなく、その場しのぎの対応をしたデベロッパーに端を発します。スコープが過剰なCI/CD変数や設定ファイル、あるいは「ちょっとの間だけ」とコミットされた.envファイルに認証情報が紛れ込みます。

GitLab 19.0でパブリックベータ版として提供開始したGitLab Secrets Managerは、コードとパイプラインを実行しているのと同じプラットフォームで認証情報を管理します。各シークレットは必要なジョブにスコープされ、既存のアクセス制御で管理されます。シークレットが意図しない場所に保存されるリスクが減り、万一漏洩した場合でも、セキュリティチームとエンジニアリングチームへの影響を最小限に抑えられます。

シークレットの典型的な保存先

デベロッパーはしばしば、CI/CD変数にシークレットを格納するという方法をデフォルトで選択します。プロジェクトまたはグループレベルで変数を設定し、値をマスクしてパイプラインを更新する——このやり方では、値がすべてのジョブに注入され、パイプラインへのアクセス権を持つ誰もが読み取れる状態になります。最小権限の原則に反しますが、ビルドは動き続けます。

よく使われる解決策はスタンドアロンの vault です。シークレットをCI/CD設定から切り出せるものの、恒久的な運用コストが発生します——追加で認証が必要なシステム、別途管理が必要なアクセスモデル、インシデント時に突き合わせが必要な別の監査ストリームです。

既存のプロジェクトとパイプラインでSecrets Managerを試す

GitLab Secrets Managerは、OpenBao上に構築されたGitLabのネイティブ機能です。既存のGitLabプラットフォームに組み込まれているため、認証情報は既存のプロジェクトおよびグループ構造の中に留まります。

デベロッパーは.gitlab-ci.ymlのsecrets:キーワードを使って、CI/CD変数からシークレットを移行できます：

      deploy:
  secrets:
    DATABASE_PASSWORD:
      gitlab_secrets_manager:
        name: db-password
  script:
    - deploy --password $DATABASE_PASSWORD

    

デフォルトでは、GitLabはシークレットを一時ファイルに書き込み、そのパスをジョブにスコープされた環境変数として提供します。値そのものではなくパスを渡すことで、サブプロセス、クラッシュダンプ、テレメトリーへの露出リスクを低減できます。

使い慣れたアクセスモデルをそのまま活用

スタンドアロンのシークレットマネージャーでは、2つのアクセスモデルを並行して管理しなければなりません。GitLabで構築済みのすべてのチーム、アプリケーション、権限境界を、シークレットツール側でも再構築し、メンバーの入退社やロール変更に合わせて同期し続ける必要があります。2つのシステムが乖離すると——退職したエンジニアの認証情報が残ったままだったり、アプリケーションが不要なアクセス権を蓄積したりすると——そのギャップが悪用される可能性があります。

Secrets Managerは、既存のグループおよびプロジェクト構造をシークレットの分離境界として使用するため、別途構造を構築・管理する必要はありません。ユーザー、グループ、ロールごとに読み取り・作成・更新・削除の権限を設定できます。グループレベルで作成されたシークレットはその配下のすべてのプロジェクトで利用でき、共通の認証情報は一度定義するだけで必要な場所に継承されます。メンバーがプロジェクトから削除されると、そのプロジェクトのシークレットへのアクセス権も即座に失われます。

GitLab Secrets Managerに保存されたプロジェクトの認証情報

必要なジョブにのみスコープされたシークレット

3月にAxios npmパッケージが侵害された際、感染バージョンを実行していた組織は、パイプラインが触れたすべての認証情報が攻撃者の手に渡ったものとして対応を迫られました。漏洩したシークレットのローテーションと、それらのシークレットがアクセスできるすべてのシステムの監査を、短期間で実施しなければなりませんでした。

シークレットのスコープが広いほど、漏洩時の対応コストは増大します——そのコストはセキュリティチームだけでなく、マージのブロックやビルドの破損という形でデベロッパーにも及びます。スコープを絞ることで、侵害された認証情報が実際にアクセス権を持っていたシステムだけに対応範囲を限定できます。

Secrets Managerは、各認証情報を必要なジョブにスコープすることで、侵害時の影響範囲を最小化します。ジョブがシークレットを取得できるかどうかは、3つのジョブ属性に基づいて判断されます——ターゲットとする環境、実行するブランチ、そのブランチが保護されているかどうかです。環境とブランチにはワイルドカードを使用できるため、すべてのケースを列挙する必要はありません。スコープはGitLabがすでに追跡しているジョブ属性で定義されるため、パイプラインと照合するための別システムも不要です。

ジョブが実行されると、必要なシークレットの値をリクエストします。シークレットのバックエンドはジョブのIDを検証し、ブランチと環境がスコープルールと一致するかを確認してから値を返します。条件を組み合わせることもでき、保護されたブランチで実行され、かつproduction/*環境をターゲットとするジョブのみに認証情報を渡すルールを1つで定義できます。ジョブ終了後、シークレットは破棄されます。Runnerには何も残らず、ジョブログはマスクされます。一方、CI変数はプロジェクト設定の中に無期限に残り続けます。

シークレットをパイプラインまでトレースする

シークレットが漏洩したり依存関係が侵害されたりした場合、対応者はその認証情報を使用したすべてのパイプラインとジョブまでさかのぼる必要があります。これはCIシステム、シークレットツール、IDプロバイダー、その認証情報が触れた他のシステムのログを突き合わせる作業を伴います。

GitLab Secrets Managerは、プロジェクトおよびグループレベルのシークレットに対する作成・更新・削除イベントを、プラットフォームの他のイベントと同じ監査証跡に記録します。シークレットの変更履歴は、他のガバナンス記録と一元管理されます。CI/CDパイプラインからのシークレット読み取りは、元のパイプラインとジョブIDを含む監査イベントとしてストリーミングされるため、複数システムにまたがるデータを手動で突き合わせることなく、シークレットの使用箇所を追跡できます。監査ログはSelf-Managed版デプロイメントで現在利用可能で、GitLab.comへの対応はパブリックベータプログラム期間中に提供予定です。

Secrets Managerの動作を確認する

パブリックベータ版に参加する

GitLab Secrets Managerは、GitLab.comおよびSelf-Managed版デプロイメントのPremiumおよびUltimateユーザー向けにパブリックベータ版として提供中です。GitLab Dedicated版のサポートも近日提供予定です。

GitLab.comでは、オプトインして最初のシークレットを作成できます。Self-Managed版デプロイメントでは、インストール手順に従い、デベロッパーとしてSecrets Managerを使用する方法もご確認ください。

HashiCorp Vault、AWS Secrets Manager、Azure Key Vault、Google Cloud Secret Managerとの連携はGitLab Secrets Managerと並行して動作するため、独自のスケジュールで導入を進めることができます。

Secrets Managerはベータ版期間中は無料でご利用いただけます。一般提供（GA）後はGitLabクレジットでの課金となる有料機能となります。課金が発生する前にオプトインが必要で、一般提供開始前に事前通知をお送りします。

Secrets Managerをお試しいただいたら、フィードバックをお寄せください。一般提供前の機能改善に反映させていただきます。

GitLab 19.0の詳細はこちら

• GitLab 19.0がリリースされました
• GitLab Duo Agent Platform Self-Hostedでさらに多くのAIモデルに対応
• マージリクエストを手動作業から自動化ワークフローへ
• 組織全体でCIコンポーネントの使用状況を追跡