G-gen の杉村です。Google Cloud（旧称 GCP）の IAM には、サービスエージェント という仕組みがあります。

概要

サービスエージェントとは

サービスエージェントとは、Google Cloud サービスが内部的に用いる、特別なサービスアカウントです。プロダクトの API を有効化したときなどに自動的に作成されるため、ユーザーが意識することはあまりありませんが、初期設定時や仕組みの構築の際に、サービスエージェントに対して権限の付与が必要になることがあります。

サービスエージェントは、Google Cloud サービスが別のサービスを呼び出すときなどに使用されます。

サービスエージェントは通常、プロジェクトに所属しますが、組織レベルで作成されるサービスエージェントもあります。

なおサービスエージェントは別名として「Google マネージドサービスアカウント」または「Google が管理するサービスアカウント」とも呼ばれます。

参考 : Service agents

サービスエージェントとサービスアカウントの違い

サービスエージェントとサービスアカウントの違いは何でしょうか。

サービスエージェントは、サービスアカウントの一種です。サービスアカウントの方が広い概念です。

ユーザーが作成する通常のサービスアカウントは、Google Cloud コンソール画面の「IAM と管理＞サービスアカウント」で一覧表示できます。

しかし、サービスエージェントは Google Cloud が管理する特殊なサービスアカウントのため、この一覧には表示されません。

また、プロジェクトの IAM ロール一覧画面（IAM と管理＞ IAM）でも、普段は非表示になっています。Google 提供のロール付与を含める というチェックボックスをオンにすると、非表示だったサービスエージェントと IAM ロールの紐づき（バインディング）が表示されます。

当記事では、代表的な Google Cloud サービスで、サービスエージェントがどのように用いられているかを紹介します。

Compute Engine

概要

あるプロジェクトで Compute Engine API を有効化すると、プロジェクトに以下の名称のサービスアカウントが生成されます。これが、Compute Engine のサービスエージェントです。

service-(プロジェクト番号)@compute-system.iam.gserviceaccount.com

なお Compute Engine の API を有効化すると (プロジェクト番号)-compute@developer.gserviceaccount.com という名称で、Compute Engine のデフォルトサービスアカウントが生成されますが、これとサービスエージェントは別物です。

デフォルトサービスアカウントは VM にアタッチするものですが、サービスエージェントは後述の用途のためにサービス側が使うものです。ユーザーが意識することはほとんどありません。

このサービスエージェントには最初から Compute Engine サービスエージェント というロールがプロジェクトレベルで付与されています。このロール紐づきを削除してしまうと、Compute Engine の正常な動作は保証されません。

参考 : Compute Engine サービスエージェント

Compute Engine のサービスエージェントは、内部的に様々な用途に用いられていますが、普段はユーザーに意識されることはありません。

しかし、以下の用途の際にサービスエージェントを意識することがあります。

永続ディスクの CMEK による暗号化・復号
VM の起動・停止スケジューリング

永続ディスクの CMEK による暗号化・復号

以下のスクリーンショットは、永続ディスクの暗号化方式を CMEK での暗号化にするよう選択したときのメッセージです。

Compute Engine サービスエージェントに、暗号鍵に対して Cloud KMS 暗号鍵の暗号化 / 復号（cloudkms.cryptoKeyEncrypterDecrypter）ロールが必要なことを示しています。ユーザーに代わってサービスエージェントがディスク I/O の都度、鍵を利用して透過的な暗号化・復号を行っているのです。

ここで権限を持たせる必要があるのは、VM にアタッチしたサービスアカウントではなく、サービスエージェント**である点に注意が必要です。

VM の起動・停止スケジューリング

VM の自動起動・停止のスケジュールを設定する際にも、サービスエージェントが関係します。

参考 : VM インスタンスの起動と停止をスケジュールする

Compute Engine ではコンソール等から、cron 形式で VM の自動停止・起動をスケジューリングできます。

このスケジューリング機能では、Google Cloud がユーザーに代わって VM を停止あるいは起動します。このときに、サービスエージェントの IAM 権限が使われます。

サービスエージェントにインスタンス停止・起動の IAM 権限が無い場合、以下のようなエラーメッセージが表示されます。

Compute Engine System service account service-(PJ-NUMBER)@compute-system.iam.gserviceaccount.com needs to have [compute.instances.start,compute.instances.stop] permissions applied in order to perform this operation.

このメッセージが出た場合、サービスエージェントに、プロジェクトレベルで Compute インスタンス管理者（v1） (roles/compute.instanceAdmin.v1）などのロールを付与する必要があります。

Cloud Storage

概要

Cloud Storage にもサービスエージェントが存在します。名称は以下のとおりです。

service-(プロジェクト番号)@gs-project-accounts.iam.gserviceaccount.com

サービスエージェントの名称はコンソールの「Cloud Storage ＞設定」画面から確認したり、gcloud コマンドラインで gcloud storage service-agent --project=${PROJECT_ID} を実行することでも確認できます。

参考 : Cloud Storage サービスエージェントの取得
参考 : サービスエージェント

Cloud Storage のサービスエージェントは、以下のような用途で用いられます。

Pub/Sub 通知
CMEK による暗号化・復号

Pub/Sub 通知

Cloud Storage ではオブジェクトに変更（作成・削除等）があった際に、Pub/Sub に通知することができます。

参考 : Cloud Storage の Pub/Sub 通知

この機能は、オブジェクト変更をトリガにして Cloud Functions を起動し、後処理を実装する際などに用いられます。

Cloud Run functions を Cloud Storage トリガー関数という形で実装することがありますが、バックエンドではこの Pub/Sub 通知が用いられています。以下の記事も参照ください。

blog.g-gen.co.jp

Cloud Storage サービスが Pub/Sub にメッセージをパブリッシュ（通知）する際には、サービスエージェントに権限が必要です。上記の記事の Cloud Storage サービスエージェントに権限付与 の項で示しているように、権限を付与する必要があります。

CMEK による暗号化・復号

Compute Engine と同じように、Cloud Storage でも、ストレージの透過的な暗号化に顧客管理の暗号鍵（CMEK）を指定できます。

その際にサービスエージェントがユーザーに代わって鍵を使い、データを暗号化・復号します。

サービスエージェントは、秘密鍵に対して Cloud KMS 暗号鍵の暗号化 / 復号（cloudkms.cryptoKeyEncrypterDecrypter）ロールを持つ必要があります。

プロジェクトレベルでサービスエージェントに上記ロールを付与するか、鍵に個別にロールを付与します。

Cloud Logging

概要

Cloud Logging のサービスエージェントは複数の種類があり、それぞれ用途が異なります。

No	名称	用途
1	service-(プロジェクト番号)@gcp-sa-logging.iam.gserviceaccount.com	サービスがバックエンドで利用
2	cmek-p(プロジェクト番号)@gcp-sa-logging.iam.gserviceaccount.com	ログバケットの透過的な暗号化 (CMEK)
3	p(プロジェクト番号)-(6桁数字)@gcp-sa-logging.iam.gserviceaccount.com	ログシンクの書き込み ID

サービスがバックエンドで利用

service-(プロジェクト番号)@gcp-sa-logging.iam.gserviceaccount.com にはデフォルトで、プロジェクトレベルで Cloud Logging サービスエージェント ロールが付与されています。

この IAM ロールは、BigQuery データセットの作成とリンクの権限を持っていることから、Log Analytics 機能で用いられていることが分かります。

ログバケットの透過的な暗号化 (CMEK)

cmek-p(プロジェクト番号)@gcp-sa-logging.iam.gserviceaccount.com は、CMEK 暗号化に用いられます。Compute Engine や Cloud Storage の項で前述した内容と、ほぼ同等です。

KMS の暗号鍵に対して、このサービスエージェントが Cloud KMS 暗号鍵の暗号化 / 復号（cloudkms.cryptoKeyEncrypterDecrypter）ロールを持つことで、透過的な暗号化が行われます。

参考 : Logging のストレージデータを保護する鍵を管理する

なお p(プロジェクト番号) の部分は、組織レベルのログバケットであれば p(組織番号) になり、フォルダレベルであれば f(フォルダ番号) となります。

ログシンクの書き込み ID

p(プロジェクト番号)-(6桁数字)@gcp-sa-logging.iam.gserviceaccount.com は、書き込み ID と呼ばれるサービスアカウント（サービスエージェント）です。

Cloud Logging では、ログシンク（ログルーター）を作成することで、Cloud Logging に入ってきたログを様々な宛先に振り分けて保存することが可能です。

ログシンクが書き込み可能な宛先は「Cloud Logging ログバケット」「Cloud Storage バケット」「BigQuery データセット」「Pub/Sub」などですが、ログシンクを作成する際、宛先が「そのシンクが存在するプロジェクトの Cloud Logging ログバケット以外」だった場合、シンクは書き込み ID（Writer Identity）と呼ばれる専用のサービスアカウントを使います。

書き込み ID の名称を確認するには、Google Cloud コンソールでログシンクを選択し「シンクの詳細を表示する」を押下したり、gcloud で gcloud logging sinks describe ${SINK_NAME} を実行します。

シンクはプロジェクトに作成したり、あるいはフォルダレベル / 組織レベルで作成することができます。プロジェクトレベルで作成したシンクの書き込み ID は p(プロジェクト番号)-(6桁数字)@gcp-sa-logging.iam.gserviceaccount.com となり、フォルダレベルなら f(フォルダ番号)-(6桁数字)@〜 、組織レベルなら o(フォルダ番号)-(6桁数字)@〜 となります。

またシンクを作成するごとに書き込み ID が別個に生成され、一意の6桁の数字が払い出されてサービスアカウント名になります。

シンク（ログルーター）については以下の記事もご参照ください。

参考 : Cloud Loggingの概念と仕組みをしっかり解説 - G-gen Tech Blog - ログルーティングとログの保存

Looker Studio

概要

Google Cloud の無償のダッシュボードツールである Looker Studioにも、サービスエージェントが存在します。サービスエージェントの名称は以下です。

service-org-(組織番号)@gcp-sa-datastudio.iam.gserviceaccount.com

サービスエージェント名は、以下の URL にアクセスすることで確認可能です。

参考 : https://datastudio.google.com/serviceAgentHelp

データソースへの認証

Looker Studio のサービスエージェントは、「データソースへの認証をサービスアカウントで行う」場合に用います。

Looker Studio には多様なコネクタが用意されており、BigQuery や Cloud SQL、Cloud Storage 上の CSV などにアクセスしてデータを可視化することができます。

参考 : Looker Studio | Connect to Data

Google Cloud 上のリソースをデータソースとして扱う際には、認証が必要です。Looker Studio では、データソースへの認証方法として以下を選択できます。

ダッシュボードのオーナーの Google アカウント
ダッシュボードの閲覧者の Google アカウント
サービスアカウント

データソースへの認証にサービスアカウントを使えば、利用者にはダッシュボードの閲覧権限だけを与えるだけでよくなります。Looker Studio レポートからデータソースへのアクセスには、サービスアカウントの認証情報が使われます。

この 3. の用途の際に、サービスエージェントが関係してきます。

認証情報として使うサービスアカウントは、Google Cloud プロジェクトに作成してデータソースへのアクセス権限（BigQuery 閲覧者等）を付与しておきます。

その後 Looker Studio がこのサービスアカウントの権限を借用できるように、作成したサービスアカウントに対して、Looker Studio サービスエージェントをサービスアカウントトークン作成者（iam.serviceAccount.getAccessToken）ロールとして紐づけます。

図示すると以下のようになります。