Service Account Impersonation

GCP の IAM が提供する 「サービスアカウントを借りる」機能 。鍵を発行せず、iamcredentials.googleapis.com の generateAccessToken API で対象 SA の短命アクセストークンを取得し、その SA として API を呼び出す。

概要

呼び出し側のプリンシパル（人間ユーザー・別の SA・WIF 連携 ID）が、 対象サービスアカウントに対して roles/iam.serviceAccountTokenCreator を持つ ことを条件に、対象 SA の access token を発行できる。発行されたトークンは通常 1 時間で失効 する短命なものであり、 静的キーを発行しない という点で「キーレス運用」の核を担う。

主な用途：

WIF + Impersonation：Workload Identity Federation で連携 ID が SA を借り、CI/CD からクラウド API を実行する
権限境界の設定：低権限の人間ユーザーから、高権限 SA を限定的に借りる
環境間の権限切替：管理用ワークロードから、各環境の SA を切り替えて操作する

WIF との関係

WIF の credential JSON に service_account_impersonation_url を含めると、 連携 ID → 対象 SA → リソース という 1 段の impersonation 経路が成立する。これが GCP の WIF で長らく標準だった方式（第 2 世代 = “WIF + Service Account Impersonation”）。

{
  "type": "external_account",
  "audience": "//iam.googleapis.com/projects/<num>/locations/global/workloadIdentityPools/<pool>/providers/<provider>",
  "service_account_impersonation_url":
    "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/<target-sa>:generateAccessToken",
  "credential_source": { "file": "/tmp/oidc_token" }
}

近年 GCP は Direct Resource Access（連携 ID 自身に IAM ロールを直接付与する principal:// / principalSet:// 方式）を推奨に格上げしており、Impersonation を経由する必要がない場面は徐々に減っている。ただし、複数 SA を切り替える運用や、特定 API（Cloud Storage signed URL 生成等）では今も Impersonation が必須または最適。

「インパーソネーション」と「なりすまし」

日本語では「なりすまし」と訳されることが多いが、文脈によって意味が異なる点に注意。

用語	意味
Service Account Impersonation（公式）	IAM 上で許可された範囲内で対象 SA のトークンを取得する正規機能
インパーソネーションあり（社内慣用）	Principal SA → Target SA の 2 段階で SA を借りる構成
インパーソネーションなし（社内慣用）	WIF から直接 Target SA を 1 段階で借りる構成（公式分類では Impersonation 利用中）
なりすまし（一般語）	攻撃文脈で他者を装う行為（こちらは不正）

社内での「インパーソネーションあり / なし」は 「中継 SA を経由するか」 の区別であって、「impersonation API を呼ぶか」ではない。詳しくは GitLab → GCP 認証方式の 3 世代と CTS の選択を参照。

セキュリティ上の注意

roles/iam.serviceAccountTokenCreator は強い権限。 付与先と対象 SA の組合せを最小限に絞る
監査ログ（Cloud Audit Logs）には Impersonation の主体と対象が両方記録される。 監査時はチェーンを追う前提で見る
経路が長くなるほどデバッグと最小権限維持が難しい。Direct Resource Access で済む経路はそちらを優先

概要

WIF との関係

「インパーソネーション」と「なりすまし」

セキュリティ上の注意

関連記事・用語

外部リソース