GCP におけるサービスアカウントとは
GCP 上のリソースを操作する権限を付与できるプリンシパルの1つ。
エンドユーザーではなく、システムが利用するアカウントである。
また、サービスアカウントはリソースでもある。
すなわち、あるサービスアカウントに対する操作権限(以下例)をそのサービスアカウント自身に付与したり、別のプリンシパルに付与することができる。
- 特定のサービスアカウントを特定の GCP リソースへ紐づける(そのリソースのシステムが利用するアカウントを設定できる)
roles/iam.ServiceAccountUser
- 特定のサービスアカウントへなりすます(対象サービスアカウントの OAuth2アクセストークン, OIDC IDトークン を生成できる)
roles/iam.ServiceAccountTokenCreator
-
roles/iam.ServiceAccountOpenIdTokenCreator
(OIDC IDトークンの生成のみ可能版)
- サービスアカウントを削除できる
roles/iam.serviceAccountDeleter
参考: サービスアカウントの権限
サービスアカウントでリソースを操作する
大きくは、以下3パターンがある
1. 接続されたサービスアカウント
サービスアカウントが紐づけられた GCP のリソースが、自身および他のリソースを操作する場合のみ。
- 「リソースにデフォルトで使用するサービスアカウントを紐づけておく」と、このパターンが自動で適用される
- サービスアカウントが紐づけられたリソースが、自身およびその他のリソースにアクセスすると、サービスアカウントの認証と認可が自動的行われる
2. サービスアカウントキーの利用
GCP 外から GCP リソースを操作する場合に。
前提
GCP 外のシステムが、リソースを操作するシステムがサービスアカウントキーを使える状態であること
手順
サービスアカウントキーを利用して自身がサービスアカウントであることを認証してもらい、そのサービスアカウントに設定されている権限を認可してもらう
3. サービスアカウントになりすます
GCP 外から GCP リソースを操作する場合に。主に ローカル環境から GCP リソースを操作したいときに。
前提
- 「対象のサービスアカウントの有効期間の短い認証情報(☆)」を生成できる権限(
roles/iam.serviceAccountTokenCreator
やroles/iam.serviceAccountOpenIdTokenCreator
)を持つプリンシパルがあること - GCP 外のシステムが、上記のプリンシパルとして認証可能であること
手順
- ☆ を生成できるプリンシパル(Google アカウントだったり, 別のサービスアカウントだったり)で認証する。
そのプリンシパルで Service Account Credentials API を叩いて ☆ を発行する。 - ☆ を使いつつ GCP リソースにアクセスする。
参考: