GitLabシークレットマネージャー
- プラン: Premium、Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed
- ステータス: ベータ版
シークレットは、CI/CDジョブが機能するために必要な機密情報を表します。シークレットには、アクセストークン、データベース認証情報、プライベートキーなどがあります。
ジョブにデフォルトで常に利用可能なCI/CD変数とは異なり、シークレットはジョブによって明示的にリクエストされなければなりません。
GitLabシークレットマネージャーを使用して、プロジェクトおよびグループのシークレットと認証情報を安全に保存および管理します。
GitLabシークレットマネージャーのパブリックベータ版は、GitLab Premium and Ultimateのお客様が利用できます。パブリックベータ版はGitLab.comまたはSelf-Managedインスタンスでオプトインできます。
GitLab.comでのオプトイン
GitLab.comでは、トップレベルグループのオーナーが、そのグループのGitLabシークレットマネージャーをオプトインできます。トップレベルグループでオプトインすると、そのグループ内のすべてのサブグループおよびプロジェクトで利用可能になります。
前提条件:
- トップレベルグループのオーナーロールが必要です。
- グループはGitLab Premium or Ultimateティアである必要があります。
オプトインするには:
- 左サイドバーで検索または移動先を選択し、トップレベルグループを見つけます。
- 設定 > 一般を選択します。
- 権限とグループ機能を展開します。
- Secrets Managerの切替をオンにします。
オプトイン後、グループおよびプロジェクトのオーナーは、サブグループおよびプロジェクトのシークレットマネージャーを個別に有効にできます。手順については、Enable for a group or projectを参照してください。
Self-Managedインスタンスでのオプトイン
Self-Managedインスタンスでは、まず管理者がインスタンスレベルでGitLabシークレットマネージャーをオプトインする必要があります。オプトイン後、オーナーは、自分のグループおよびプロジェクトでそれを有効にできます。
前提条件:
- GitLabインスタンスへの管理者アクセス権が必要です。
- GitLab 19.0以降。
- OpenBaoがインストールおよび設定されている必要があります。詳細については、administrationを参照してください。
オプトインするには:
- 左側のサイドバーの下部で、管理者を選択します。
- 設定 > 一般を選択します。
- 展開するGitLabシークレットマネージャー。
- Secrets Managerの切替をオンにします。
オプトイン後、グループおよびプロジェクトのオーナーは、自分のネームスペースでシークレットマネージャーを有効にできます。手順については、Enable for a group or projectを参照してください。
グループまたはプロジェクトでの有効化
プロジェクトの場合
前提条件:
- プロジェクトのオーナーロールが必要です。
プロジェクトでGitLabシークレットマネージャーを有効または無効にするには:
上部のバーで、検索または移動先を選択して、プロジェクトを見つけます。
左側のサイドバーで、設定 > 一般を選択します。
可視性、プロジェクトの機能、権限を展開します。
シークレットマネージャーの切替をオンにして、シークレットマネージャーがプロビジョニングされるのを待ちます。
後でプロジェクトのシークレットマネージャーを無効にすると、プロジェクトのすべてのシークレットは完全に削除されます。これらのシークレットは復元できません。
プロジェクト用に定義されたシークレットは、同じプロジェクトのパイプラインからのみアクセスできます。
グループの場合
前提条件:
- グループのオーナーのロールを持っている必要があります。
グループでGitLabシークレットマネージャーを有効または無効にするには:
上部のバーで、検索または移動先を選択して、グループを見つけます。
左側のサイドバーで、設定 > 一般を選択します。
権限とグループ機能を展開します。
シークレットマネージャーの切替をオンにして、シークレットマネージャーがプロビジョニングされるのを待ちます。
後でグループのシークレットマネージャーを無効にすると、グループのすべてのシークレットは完全に削除されます。これらのシークレットは復元できません。
グループ用に定義されたシークレットは、グループ直下のプロジェクト、またはそのサブグループ階層内のパイプラインからのみアクセスできます。
シークレットを定義する
シークレットマネージャーにシークレットを追加して、セキュアなCI/CDパイプラインとワークフローに利用できます。
- トップバーで検索または移動先を選択し、プロジェクトを見つけます
- セキュリティ > シークレットマネージャーを選択します。
- シークレットを追加を選択し、詳細を入力します:
- Name: プロジェクト内で一意である必要があります。
- 値: 10 KB（10,000バイト）以下である必要があります。
- 説明: 最大200文字。
- 環境: 設定できる項目:
- ブランチ: プロジェクトの設定でのみ存在するオプションです。設定できる項目:
- 特定のブランチ。
- ワイルドカードブランチ（
*文字を含む必要があります）。
- 保護: グループの設定でのみ存在するオプションです。オプション。エクスポートするシークレットを保護ブランチで実行されているパイプラインにのみ。
- ローテーションのリマインダー: オプション。設定された日数が経過した後、シークレットをローテーションするようメールリマインダーを送信します。最低7日間。
シークレットを作成した後、それをパイプラインの設定またはジョブスクリプトで使用できます。
シークレットの値は、シークレットが作成または更新されたときに定義された特定の環境またはブランチで実行されているすべてのCI/CDパイプラインジョブからアクセス可能です。これらのシークレットの値にアクセスする権限を持つユーザーのみが、指定された環境またはブランチのジョブを実行できるようにしてください。
ジョブスクリプトでシークレットを使用する
プロジェクトのシークレットの場合
前提条件:
- GitLab Runner 19.0以降。
シークレットマネージャーで定義されたシークレットにアクセスするには、secretsおよびgitlab_secrets_managerキーワードを使用します。
ファイルタイプの変数と同様に、シークレットは次の環境変数として利用可能になります:
- シークレットのキーを環境変数名として使用します。
- シークレットの値は一時ファイルに保存されます。マスクされた変数とは異なり、シークレットにはスペースや改行を含めることができます。
- その一時ファイルのパスは環境変数値として扱われる。
例:
job:
secrets:
KUBE_CA_PEM:
gitlab_secrets_manager:
name: kube-cert
script:
- kubectl config set-cluster e2e --server="https://example.com" --certificate-authority="$KUBE_CA_PEM"もしジョブがシークレットの値を出力する場合（例えばcat $KUBE_CA_PEMを実行することによって）、GitLabはジョブログ内の値を[MASKED]に置き換えます。
グループのシークレットの場合
前提条件:
- GitLab Runner 19.0以降。
グループシークレットにアクセスするには:
secretsおよびgitlab_secrets_managerキーワードを使用します。- シークレットマネージャーのソースを
sourceフィールドでgroup/<full-path-to-group>の形式で指定します。
例:
job:
secrets:
TEST_SECRET:
gitlab_secrets_manager:
name: foo
source: group/<full-path-to-group>
script:
- cat $TEST_SECRETシークレットの権限を管理する
プロジェクトの場合
前提条件:
- プロジェクトのオーナーロールを持つユーザーは、シークレットの権限を管理できます。
- プロジェクトのメンテナーロールを持つユーザーは、定義された権限を表示できます。
- プロジェクトでシークレットマネージャーが有効になっている必要があります。
プロジェクトのシークレットの権限を更新するには:
- 上部のバーで、検索または移動先を選択して、プロジェクトを見つけます。
- 左側のサイドバーで、設定 > 一般を選択します。
- 可視性、プロジェクトの機能、権限を展開します。
- シークレットマネージャーの下のシークレットマネージャーのユーザー権限セクションで、ユーザー権限を管理できます:
- 追加を選択して、特定のユーザー、グループ、またはロールの権限ルールを追加します。
- 権限スコープを読み取り、書き込み（作成および更新）、およびシークレットの削除に設定できます。
グループの場合
前提条件:
- グループのオーナーロールを持つユーザーは、シークレットの権限を管理できます。グループのオーナーロールを持つユーザーのみが、定義された権限を表示できます。
- グループでシークレットマネージャーが有効になっている必要があります。
グループのシークレットの権限を更新するには:
- 上部のバーで、検索または移動先を選択して、グループを見つけます。
- 左側のサイドバーで、設定 > 一般を選択します。
- 権限とグループ機能を展開します。
- シークレットマネージャーの下のシークレットマネージャーのユーザー権限セクションで、ユーザー権限を管理できます:
- 追加を選択して、特定のユーザー、グループ、またはロールの権限ルールを追加します。
- 権限スコープを読み取り、書き込み（作成および更新）、およびシークレットの削除に設定できます。
グループのオーナーロールを持つユーザーは、シークレットマネージャーでのすべての操作を実行する権限を常に持っています。
プロジェクトまたはグループの削除
プロジェクトを削除またはグループを削除すると、シークレットとともに:
- プロジェクトまたはグループのシークレットマネージャーは無効になり、シークレットストレージエンジンから削除されます。
- すべてのシークレットは完全に削除されます。
プロジェクトまたはグループの転送
プロジェクトを転送またはグループを転送すると、シークレットとともに:
- プロジェクトまたはグループ用に定義されたシークレットは、新しいネームスペースのプロジェクトまたはグループには転送されません。
- プロジェクトまたはグループのシークレットマネージャーは無効になり、シークレットストレージエンジンから削除されます。
- すべてのシークレットは完全に削除されます。
シークレットのローテーション通知
プロジェクトのオーナーロールを持つユーザーは、シークレットの設定で指定された日にシークレットをローテーションするようメール通知を受け取ります。
一般公開時の価格設定
GitLabシークレットマネージャーはオープンベータ期間中は無料ですが、一般公開されるとGitLabクレジットを消費します。サービスの中断を避けるため、一般公開前にGitLabクレジットのオンデマンド課金をオプトインする時間を与えるため、ご連絡いたします。
フィードバックを提供する
パブリックベータ期間中にフィードバックを共有したり、イシューを報告したりするには、GitLabシークレットマネージャー: パブリックベータ版での顧客フィードバックイシュー。
トラブルシューティング
エラー: reading from Vault: api error: status code 403
CI/CDパイプラインジョブがシークレットをフェッチするのを試みるとき、このエラーが返される可能性があります:
ERROR: Job failed (system failure): resolving secrets: getting secret: get secret data: reading from Vault: api error: status code 403: 1 error occurred: * permission deniedこのエラーは、ジョブが存在しないか削除されたシークレットをフェッチするのを試みたときに発生します。
エラー: inline auth JWT is required
CI/CDパイプラインジョブがシークレットをフェッチするのを試みるとき、このエラーが返される可能性があります:
ERROR: Job failed (system failure): resolving secrets: creating vault client: configuring inline auth: inline auth JWT is requiredこのエラーは、シークレットが属すると予想されるプロジェクトまたはグループに対して、シークレットマネージャーインスタンスがまだプロビジョニングされていない場合に発生します。Runnerは、シークレットマネージャーロールがまだ存在しないため、認証を設定できません。
このエラーを解決するには、プロジェクトまたはグループでSecrets Managerを有効化します。
プロビジョニングが完了するのを待ち、シークレットを作成してからパイプラインを再実行してください。