GCP 認証とVault: サービスアカウント連携の実務とAssociate対策

GCP上のワークロードがVaultに安全に接続し、必要なときだけGCPの短期資格情報（アクセストークンや一時鍵）を取得できる構成は、ゼロトラストと最小権限を両立させるうえで定番です。

本稿では、VaultのGCP Auth MethodとGCP Secrets Engineを中心に、サービスアカウント連携の設計・構築・運用の勘所を、Associateレベルの試験対策目線で要点化します。

前提と用語整理: Auth MethodとSecrets Engineの違い

Vaultでは、認証（誰か）とシークレット発行（何を渡すか）を明確に分離します。GCP連携では、Auth Methodとしての「GCP Auth」と、動的資格情報を発行する「GCP Secrets Engine」を組み合わせるのが基本です。

GCP Authは、GCEインスタンスのアイデンティティやサービスアカウントの署名付きJWTを用いて、クライアントをVaultにログインさせます。GCP Secrets Engineは、指定されたロールに基づき、短期のアクセストークンやサービスアカウント鍵を動的に払い出します。

• Auth Method: Vaultトークンを得るための入り口（認証）。ロールとポリシーの付与が肝。
• Secrets Engine: Vaultが発行・管理するシークレットの出し口。TTLとロール設定が肝。
• GCPサービスアカウント: GCP側の主体。Vault側では「どのSAからの要求を許すか」を境界条件として扱う。

最小ポリシー例（VaultでGCP秘密の読み出しを許可）

path "gcp/token/app-role" {
  capabilities = ["read"]
}

アーキテクチャと認証フロー（IAM/GCE）

GCP Auth Methodは2系統に大別できます。GCEタイプはGCEやGKEノードのメタデータサーバから入手できるインスタンスアイデンティティを用います。IAMタイプはサービスアカウントが署名したJWT（もしくはIAM Credentials APIで署名）を用います。どちらもVaultはGoogleの署名・公開鍵に基づく検証と、ロールの境界条件（bound_service_accountsなど）で厳格に照合します。

アプリケーションはVaultにログインしてクライアントトークンを取得し、そのトークンでGCP Secrets Engineから短命なアクセストークン等を取得する流れが基本です。長期のJSON鍵ファイルを配布せずに済む構成が実務でも推奨されます。

• GCEタイプ: インスタンスIDトークン→Vault auth/gcp/login→Vaultトークン付与
• IAMタイプ: SA署名JWT（aud/exp含む）→Vault auth/gcp/login→Vaultトークン付与
• 付与されたVaultトークン→GCP Secrets Engine呼び出し→短期アクセストークン/鍵を取得

IAMタイプのログイン例（概念）

# 1) サービスアカウントでJWTを署名（IAM Credentials API など）
#    例: gcloud iam service-accounts sign-jwt payload.json signed.jwt --iam-account SA_EMAIL
# payload.json には iss/sub/aud/iat/exp 等の標準クレームを含める（audはVaultロールに合わせる）

# 2) Vaultにログイン
vault write auth/gcp/login \
  role="app-iam-role" \
  [email protected]

# 3) 返却された client_token を使用してGCPトークン取得
vault read gcp/token/app-role

Vault側の設定手順（Auth Method と Secrets Engine）

まずGCP Auth Methodを有効化し、ロールを作成してGCPのサービスアカウントやプロジェクト境界を定義します。次にGCP Secrets Engineを有効化し、必要なスコープやインパーソネーション対象をロールで制御します。最後にロールに紐づくポリシーを用意して、アプリが読み出せるパスを限定します。

GCP Secrets EngineはVaultがGCPに対して代理でトークンや鍵を発行するため、Vault自体がGCPへ認証できる必要があります。これはApplication Default Credentials（例: Vaultサーバが付与されたサービスアカウント）や、明示的な資格情報をSecrets Engine構成に設定して実現します。

• auth enable gcp → role作成（type=iam か gce）
• secrets enable gcp → role作成（access token or key）
• ポリシーで読み取り可能なパスを限定し最小権限化

代表的なCLI手順（例）

# 1) GCP Auth Method を有効化
vault auth enable gcp

# 2) IAMタイプのロールを作成（特定SAのみ許可、TTLを短く）
vault write auth/gcp/role/app-iam-role \
  type="iam" \
  bound_service_accounts="app-sa@PROJECT_ID.iam.gserviceaccount.com" \
  bound_projects="PROJECT_ID" \
  ttl="15m" \
  max_ttl="1h" \
  policies="app-gcp-read"

# 3) GCP Secrets Engine を有効化
vault secrets enable gcp

# 4) Secrets Engine の構成（ADCを利用する例: VaultがGCPへ認証できる環境で動作）
#    credentials を省略するとADCが使われる構成が一般的
vault write gcp/config \
  ttl="3600s" \
  max_ttl="43200s"

# 5) アクセストークン発行ロール（特定SAに対して所定スコープ）
vault write gcp/roleset/app-role \
  project="PROJECT_ID" \
  secret_type="access_token" \
  [email protected] \
  token_scopes="https://www.googleapis.com/auth/cloud-platform"

# bindings.hcl の例（SAインパーソネーション許可）
# resource "//iam.googleapis.com/projects/PROJECT_ID/serviceAccounts/target-sa@PROJECT_ID.iam.gserviceaccount.com" {
#   roles = ["roles/iam.serviceAccountTokenCreator"]
# }

# 6) ポリシー（Secrets Engineの読み取りのみを許可）
cat <<'EOF' | vault policy write app-gcp-read -
path "gcp/token/app-role" {
  capabilities = ["read"]
}
EOF

GCP側の準備: サービスアカウントと権限設計

IAMタイプの認証では、署名に用いるサービスアカウント（クライアント側）がJWTを署名できる必要があります。IAM Credentials APIを用いる場合、呼び出し主体には対象SAへの roles/iam.serviceAccountTokenCreator 権限が必要です。鍵ファイルを配布せず、API署名を使うのが実務では推奨です。

Secrets Engineでアクセストークンを発行する場合、Vault（サーバ側）が対象のサービスアカウントをインパーソネートできる必要があります。Vaultが稼働するインスタンスのサービスアカウント、あるいはVaultに設定したADCに、対象SAへの roles/iam.serviceAccountTokenCreator 等を付与しておきます。

• 鍵配布を避け、signJwt/signBlobやSAインパーソネーションを使う
• TokenCreator権限は必要最小限の対象SAにだけ付与
• 監査ログ（Cloud Audit Logs）でSAのインパーソネーションを追跡

gcloudによる代表的な設定例

# クライアントが署名に使うSA
CLIENT_SA="app-sa@PROJECT_ID.iam.gserviceaccount.com"
# Vaultがインパーソネーションに使うSA（Vaultサーバに割り当て）
VAULT_SA="vault-sa@PROJECT_ID.iam.gserviceaccount.com"
# ターゲットSA（実際にトークンを取得したい主体）
TARGET_SA="target-sa@PROJECT_ID.iam.gserviceaccount.com"

# 1) クライアント側：CLIENT_SAに自身のJWT署名を許可（必要に応じて）
# signJwtを呼ぶ主体にTokenCreatorを付与
gcloud iam service-accounts add-iam-policy-binding ${CLIENT_SA} \
  --member="serviceAccount:${CLIENT_SA}" \
  --role="roles/iam.serviceAccountTokenCreator"

# 2) Vault側：VAULT_SAにTARGET_SAへのインパーソネーション権限
gcloud iam service-accounts add-iam-policy-binding ${TARGET_SA} \
  --member="serviceAccount:${VAULT_SA}" \
  --role="roles/iam.serviceAccountTokenCreator"

運用とベストプラクティス: TTL・境界条件・ポリシー

ロールの境界条件とTTLは、侵害時の影響範囲を小さく保つための第一手段です。GCP Authのロールでは、少なくとも bound_service_accounts と bound_projects は明示し、audiencesやリージョン・ゾーン境界（GCE）も可能な範囲で絞り込みます。

Secrets Engineでは、長期のサービスアカウント鍵より、短期のアクセストークン発行を優先します。どうしても鍵が必要な場合はTTLと自動破棄の仕組みを有効化し、監査ログと併せて期限前ローテーションを運用に組み込みます。

• Vaultトークン: ttl と max_ttl、periodicトークンの使い分け
• GCP Authロール: bound_service_accounts, bound_projects, audiences の最小化
• Secrets Engine: access_token優先、鍵発行は最小限、ローテーション自動化
• ポリシー: 読み取りパス限定、list権限の付与範囲も最小化
• 監査: Vault Audit DeviceとCloud Audit Logsの二重で追跡

境界条件を強めたロール構成（例）

# IAMタイプのロールで複数条件を指定
vault write auth/gcp/role/app-iam-role \
  type="iam" \
  bound_service_accounts="app-sa@PROJECT_ID.iam.gserviceaccount.com" \
  bound_projects="PROJECT_ID" \
  audiences="vault-app" \
  ttl="10m" \
  max_ttl="30m" \
  policies="app-gcp-read"

Associate試験対策: ひっかけ所の整理と比較

Associateレベルでは、Auth MethodとSecrets Engineの役割分担、ロールとポリシーの関係、TTLの意味が頻出です。GCP特有の実装細部ではなく、境界条件と短命資格情報という設計原則を説明できることが重要です。

また、同じ目的（クラウド上のワークロード認証）でも、AppRoleやKubernetes Authなど他方式とのトレードオフを問う設問が出ます。どの認証方式が前提条件や信頼境界に合うかを選べるように、観点別に整理しておきましょう。

• 認証は「Vaultトークンを得る工程」、シークレット発行は「Vaultトークンで呼ぶ工程」
• GCP Authのロール境界（bound_service_accounts等）とポリシーの違いを混同しない
• 短期アクセストークン優先、長期鍵の配布は避ける
• TTL/max_ttl/period の違いを説明できる

問題で確認

よくある質問