GCP KMS Auto Unsealにおけるサービスアカウント設計ガイド（Vault Ops向け）

VaultのAuto Unsealは、起動時に外部KMSへ依存してマスターキーを自動復号することで、手動Unsealの運用負荷を下げます。GCPではCloud KMSを用いたgcpckmsシールが公式にサポートされます。

本稿はOps視点で、GCP KMS Auto Unseal時のサービスアカウント（SA）設計にフォーカスします。試験対策としての要点（最小権限、キーマテリアルの取り扱い、Workload Identity推奨）と、実務でハマりがちな権限・ロケーション不一致・ログ監査の落とし穴を整理します。

仕組みの概観と責務境界

Vaultのgcpckmsシールは、Cloud KMSの対称鍵（purpose=encryption）を用いてVaultのマスターキーをラップ/アンラップします。Vaultプロセスは起動時に付与されたSAのADC（Application Default Credentials）でCloud KMSに対してEncrypt/Decrypt APIを呼び、復号に成功するとストレージ（RaftやGCS等）からデータを読み出せる状態になります。

設計上のポイントは、Auto Unsealに必要なのはKMSのEncrypt/Decrypt権限のみであり、KMSキーの作成・ローテーション・ポリシー変更といった管理系権限は別SAに分離することです。これにより、万一Vault実行SAが侵害されても鍵管理面の被害を抑えられます。

• VaultはKMSの「Encrypt」「Decrypt」権限のみで動作（初期化・再暗号化含む）
• KMSキーの位置（location）はVault設定のregionと一致させる
• ADCは環境に応じてGCE/GKEのアタッチSAまたはWorkload Identityを利用。鍵ファイル配布は避ける

GCP KMS Auto Unsealの呼び出しフロー（高レベル）

サービスアカウントの役割分離（最小権限の原則）

Auto Unseal要件は限定的です。運用で混同されがちな「Vault実行SA（Unseal用）」と「KMS管理SA（鍵ライフサイクル）」は必ず分けましょう。さらに、Vaultのデータストレージや監査ログ出力先に必要な権限も別途切り出すと、障害切り分けと権限境界が明確になります。

試験対策メモ: Unseal用SAに管理者ロール（Owner/Editor、KMS Admin）を付与しない。KMSキー単位スコープでroles/cloudkms.cryptoKeyEncrypterDecrypterを付ける、が鉄則です。

• Unseal用SA: KMSのEncrypt/Decryptのみ（キー単位）
• KMS管理SA: キー作成・ローテ・IAM更新（プロジェクト/キーリング単位）
• ストレージ用SA: GCSやネットワークの権限は別ロールで最小化

IAM最小権限の具体化(Cloud KMS)

Vaultのgcpckmsシールに必要な権限は、cloudkms.cryptoKeyVersions.useToEncrypt と cloudkms.cryptoKeyVersions.useToDecrypt を内包するプリンシパルロール roles/cloudkms.cryptoKeyEncrypterDecrypter です。これを対象cryptoKeyにだけ付与します。プロジェクトやキーリングに広く付けると、意図せぬ鍵利用が混入しやすくなります。

Workload Identityを使う場合は、KSA→GSAのバインドでGSA側に上記ロールを付与します。GCEの場合はインスタンス/テンプレートに対象GSAをアタッチし、不要なデフォルトEditorロール等が付いていないことを確認します。

• ロケーション一致: KMSキーlocationとVaultのregion（=KMS location）を一致させる
• 組織ポリシー/タグ: KMS鍵にラベルやタグを設定しアクセス境界を明確化
• 監査可能性: Cloud Audit LogsのKMS Decrypt/Encrypt呼び出しを必ず有効化

デプロイ別パターン(GCE / GKE Workload Identity / Autopilot)

GCE: インスタンス（またはMIG）にVault実行SAをアタッチ。メタデータ経由でADCが供給されます。鍵ファイルは不要です。

GKE Workload Identity: KSAにGSAを関連付け、PodはKSAで実行。GSAにKMSロールを付与。Autopilotでも同様の流れですが、ノードSAの直接編集は不要です。

• GCE: インスタンステンプレートでサービスアカウントを固定し、スコープはCloud APIフルアクセスでなくデフォルト（最小）推奨
• GKE: KSAにannotationsでGSAを紐付け、RBAC・PSP/PodSecurityとも整合を取る
• いずれもサービスアカウント鍵ファイルは配布しない方針を徹底

セキュリティ境界と監査（運用の要点）

監査では、KMSのEncrypt/Decrypt呼び出しをCloud Audit Logsで常時記録し、Vault起動時刻やスケールイベントと突合します。異常な頻度や時間帯のDecryptがあれば即時検知できるようにSIEM通知を設定しましょう。

鍵のローテーションはKMSで行い、Vaultは新バージョンで自動的にEncrypt/Decryptできます（Decrypterは旧バージョンにも有効）。ローテ周期と有効期限のSLOを明文化し、バックアップ/DRサイトにも同等の権限設計を反映させます。

• KMSキーは用途別に分割（Vault用を専用化）
• Decryptレート制限・失敗はアラート化
• VPC Service Controls等の境界を併用する場合はKMSのアクセスも範囲内に

実装手順とトラブルシュート

以下は最小権限での手順例です。locationはサンプルとしてglobalを用いています。実運用ではレイテンシ・レギュレーション要件に合わせて選定してください。

典型的な失敗は、location不一致、SAの付け間違い、KMSロールのスコープ過不足、Workload Identityのバインド不備です。エラー文言と監査ログの突合で早期に切り分けましょう。

• 鍵作成はpurpose=encryption（対称鍵）
• Unseal用SAにはroles/cloudkms.cryptoKeyEncrypterDecrypterのみ
• Vault設定のregionはKMSキーのlocationと一致させる

手順例（gcloud + Vault設定）

# 0) 変数
PROJECT_ID="my-project"
LOCATION="global"
KEYRING="vault-unseal"
KEY="vault-unseal-key"
UNSEAL_SA_NAME="vault-unseal-sa"
UNSEAL_SA="${UNSEAL_SA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com"

# 1) SA作成（Unseal用）
gcloud iam service-accounts create ${UNSEAL_SA_NAME} \
  --project=${PROJECT_ID} \
  --description="Vault Auto Unseal runtime SA" \
  --display-name="Vault Unseal SA"

# 2) KMSキーリングとキー（対称鍵）
gcloud kms keyrings create ${KEYRING} \
  --location=${LOCATION} --project=${PROJECT_ID}

gcloud kms keys create ${KEY} \
  --location=${LOCATION} --keyring=${KEYRING} \
  --purpose=encryption --project=${PROJECT_ID}

# 3) 最小権限の付与（cryptoKeyスコープ）
gcloud kms keys add-iam-policy-binding ${KEY} \
  --location=${LOCATION} --keyring=${KEYRING} \
  --member=serviceAccount:${UNSEAL_SA} \
  --role=roles/cloudkms.cryptoKeyEncrypterDecrypter \
  --project=${PROJECT_ID}

# 4) GCEにアタッチ（例）
#   インスタンステンプレートで --service-account ${UNSEAL_SA}
#   GKEの場合はWorkload IdentityでGSA:${UNSEAL_SA}をKSAにバインド

# 5) Vaultサーバ設定（gcpckmsシール）
#   region はKMSのlocationに合わせる（例: global, us-east1 など）
cat >/etc/vault.d/vault.hcl <<'EOF'
ui = true
listener "tcp" {
  address     = "0.0.0.0:8200"
  tls_disable = 1
}
storage "raft" {
  path = "/opt/vault/data"
}
seal "gcpckms" {
  project    = "my-project"
  region     = "global"      # = KMS location
  key_ring   = "vault-unseal"
  crypto_key = "vault-unseal-key"
}
EOF

# 6) 起動と初期化
# systemctl enable --now vault
# vault operator init -key-shares=1 -key-threshold=1
# -> Auto Unsealのため、起動時にKMSへ自動Decrypt呼び出し

# トラブルシュートの要点
# - permission denied: iamPolicyBindingの対象が"cryptoKey"か再確認
# - location mismatch: vault.hclのregionとKMSキーlocationが同一か
# - Workload Identity: KSA<->GSAバインド、トークンのAudience設定を再確認
# - 429 / rate limit: 再試行間隔、起動のスロットリング、KMS割当の見直し

問題で確認

よくある質問