Vault GCP シークレットエンジンで実現するサービスアカウント鍵の自動発行

長期運用される JSON 鍵を置き換え、ジョブ単位で短命なサービスアカウント鍵を自動発行・自動破棄するのが Vault GCP シークレットエンジンの基本ユースケースです。

本稿は、公式ドキュメントに基づく安定機能を中心に、最小権限、TTL/リース、撤回、比較選定、運用の落とし穴までを実務・試験双方の観点でまとめます。

仕組みの全体像と試験で問われやすい要点

GCP シークレットエンジンは、Vault が保持する GCP 管理用クレデンシャルを使い、GCP IAM の API でサービスアカウント鍵をその場で作成し、クライアントに返します。返却と同時にリースが付与され、TTL 到来や明示的な撤回時には、Vault が同一 API で当該鍵を削除します。これにより、鍵の使い回しを避け、漏洩リスクと監査負荷を低減できます。

KV に格納する静的シークレットとは異なり、GCP シークレットエンジンの鍵は「都度生成・期限到来で無効化される動的シークレット」です。エンジンは鍵以外に OAuth2 の access_token や id_token も発行できますが、本稿ではサービスアカウント鍵の自動発行にフォーカスします。

• クレデンシャル流通を最小化: 必要な時だけ鍵を発行、TTL で自動失効
• 監査容易性: Vault の監査ログと GCP の監査ログの双方に痕跡が残る
• 試験で要注意: roleset の secret_type、TTL と max_ttl、lease revoke の挙動、GCP の鍵上限（サービスアカウントあたり最大 10 本）

発行から自動破棄までのフロー

主要パス（エンドポイント）の把握

sys/mounts                     # エンジンの有効化
gcp/config                      # GCP 管理用クレデンシャル設定
gcp/roleset/<name>              # 発行ポリシー（ロールセット）
gcp/key/<roleset-name>         # サービスアカウント鍵の動的発行
#gcp/token/<roleset-name>      # access_token（参考）
#gcp/id-token/<roleset-name>   # id_token（参考）

前提条件と最小権限設計（GCP と Vault）

Vault が鍵を作成・削除するには、GCP 側で対象サービスアカウントに対する最小権限を付与した管理用サービスアカウント（以降、Vault 管理 SA）が必要です。鍵の作成・削除に必要なのは roles/iam.serviceAccountKeyAdmin です。access_token を発行する場合は roles/iam.serviceAccountTokenCreator が必要になります。権限は対象サービスアカウント単位に絞り込み、プロジェクト全体やフォルダ/組織に広げないのが原則です。

Vault 側では、アプリケーションに対し発行パス gcp/key/<roleset> の read 権限のみを与えます。write や list は避け、リーク面を最小化します。

• GCP: roles/iam.serviceAccountKeyAdmin（鍵の作成/削除）、必要に応じて roles/iam.serviceAccountTokenCreator（トークン）
• スコープは対象サービスアカウントに限定（ポリシーバインド時のリソース絞り込み）
• Vault ポリシーは発行パスに read のみ付与。管理操作は別ロールで分離

最小権限の具体例（GCP と Vault）

# GCP: Vault 管理 SA に対して、対象 SA の鍵管理権限を付与
# 置換: [email protected], [email protected]
#gcloud
gcloud iam service-accounts add-iam-policy-binding "SA_EMAIL" \
  --member="serviceAccount:VAULT_ADMIN_SA" \
  --role="roles/iam.serviceAccountKeyAdmin"

# Vault: アプリに鍵発行のみ許可する最小ポリシー
# 置換: ROLESET 名は ci-builder
path "gcp/key/ci-builder" {
  capabilities = ["read"]
}
# mount 情報の参照など運用系は別ポリシーに分離

導入ステップ（有効化、設定、ロールセット作成、発行）

1) エンジンを有効化し、Vault 管理 SA の JSON 認証情報を登録します。2) サービスアカウント鍵用の roleset を作成します。3) クライアントは gcp/key/<roleset> を read して鍵を取得します。鍵はリース付きで返され、TTL 到来や撤回で Vault が削除します。

roleset の secret_type は service_account_key を指定します。対象サービスアカウントと TTL/max_ttl をロールセット側で制御し、マウント側 TTL と整合させます。

• roleset は対象 SA を明示。鍵の権限は SA に付与済みの IAM に依存（roleset では付与しない）
• 鍵はファイルに保存せず標準入力から下流へ渡す運用が望ましい（必要なら一時ファイル＋適切なパーミッション）
• TTL は短く。ビルド/デプロイなどジョブ時間＋余裕数分が目安

実行例（Vault CLI）

# 1) エンジン有効化（任意パス gcp）
vault secrets enable -path=gcp gcp

# 2) GCP 管理用クレデンシャルを設定（JSON を安全に保管）
vault write gcp/config [email protected]

# 3) roleset 作成（サービスアカウント鍵を発行）
# 置換: PROJECT_ID, SA_EMAIL, TTL は要件に合わせる
vault write gcp/roleset/ci-builder \
  project="PROJECT_ID" \
  secret_type="service_account_key" \
  service_account_email="SA_EMAIL" \
  ttl="1h" max_ttl="24h"

# 4) 鍵を発行（lease 付き）
# 出力には lease_id と鍵素材が含まれる（鍵は JSON 形式）
vault read -format=json gcp/key/ci-builder > key.json

# 必要に応じて、JSON から private_key を抽出してツールへ渡すなどの処理を行う

リース、TTL、撤回の挙動（自動破棄の要点）

動的シークレットにはリースが付与されます。クライアントは lease_id を保持し、必要に応じて更新や撤回を行えます。TTL 到来時、Vault は GCP IAM の鍵削除 API を呼び出して鍵を無効化します。これが自動破棄の中核です。更新が許可される設定であれば、lease renew により有効期限のみ延長されます（鍵素材は同一）。

撤回失敗（ネットワーク断や権限逸脱など）が発生すると、Vault の失効キューが再試行します。長時間失敗が続く場合は運用者が手動撤回（Vault か GCP 側での鍵削除）を行います。試験観点では、lease revoke により即時の無効化が可能である点と、max_ttl を超えての延長は不可である点が重要です。

• TTL と max_ttl は roleset とマウントの両方で制約される
• renew は鍵素材を更新しない。素材更新は再発行が必要
• サービスアカウントあたり鍵は最大 10 本。長寿命や過発行は避ける

よく使うオペレーション（即時撤回・更新）

# 取得時の lease_id を使用（例）
LEASE_ID="gcp/key/ci-builder/abcd-efgh-..."

# 即時撤回（鍵を即座に削除）
vault lease revoke "$LEASE_ID"

# TTL 延長（許可されている場合）
vault lease renew "$LEASE_ID"

# 役割（roleset）配下の全リースを強制失効させる場合（影響大に注意）
vault lease revoke -prefix gcp/key/ci-builder

どれを使うべきか：鍵 vs アクセストークン vs ID トークン

Vault の GCP シークレットエンジンは、サービスアカウント鍵（JSON）、access_token、id_token を発行できます。鍵は広範な互換性がある一方で、私有鍵の配布というリスクがあります。トークンは短命で配布リスクが低く、可能であればトークン優先が現代的です。既存ツールが JSON 鍵を必須とする場合のみ、TTL を極小化した鍵の動的発行を選びます。

GCE/GKE など GCP 環境下では、Workload Identity やランタイムのメタデータ経由トークンと Vault を組み合わせる設計も有効です。試験では、用途に応じた secret_type の選定根拠を説明できると有利です。

• 鍵はレガシー互換、トークンは配布リスク低・最小権限で運用しやすい
• CI/CD の短時間ジョブは access_token、外部ツールの制約がある場合のみ鍵
• 対ユーザー認証連携では id_token（受け側が OIDC/JWT を要求する場合）

運用設計とトラブル対応（監査・上限・障害時）

監査: Vault の監査デバイスを有効化し、発行・撤回のメタデータを保全します。GCP 側でも Admin Activity ログで鍵の作成/削除が記録されます。両者を突き合わせると追跡性が高まります。

上限/レート: サービスアカウントあたり鍵は最大 10 本です。短い TTL と即時撤回を徹底し、ジョブ並列度と鍵本数のバランスをとります。撤回失敗時の一時的な残存も考慮します。

障害時対応: ネットワーク断や権限変更で撤回が滞留した場合、lease revoke の再試行と、必要に応じて GCP 側での手動削除を行います。DR を考慮し、TTL を障害許容時間以下に設定するのが実務的です。

• 発行結果は標準出力で下流に渡し、ファイル保存は最小化
• レスポンスラッピングで一時トークン化し、消費時にのみ展開
• CI では一時ディレクトリ（tmpfs）と最小パーミッションで取り扱う

監査とヘルスチェックの具体例

# Vault 監査をファイルに出力（権限と保管に注意）
vault audit enable file file_path=/var/log/vault_audit.log

# GCP: 残存鍵の確認と手動削除
gcloud iam service-accounts keys list \
  [email protected]

gcloud iam service-accounts keys delete KEY_ID \
  [email protected]

問題で確認

よくある質問