G-gen の杉村です。Google Cloud (旧称 GCP) の Cloud IAM には サービスエージェント という仕組みがあります。これについて解説します。

概要
- サービスエージェントとは
- サービスエージェントとサービスアカウントの違い
Compute Engine (GCE)
- 概要
- 用途
  - 永続ディスクの CMEK による暗号化・復号
  - VM の起動・停止スケジューリング
Cloud Storage (GCS)
- 概要
- 用途
  - Pub/Sub 通知
  - CMEK による暗号化・復号
Cloud Logging
- 概要
- 用途
Looker Studio (旧称データポータル)
- 概要
- 用途

概要

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

サービスエージェント とは、Google Cloud サービスが別のサービスを呼び出すときに用いる特殊なサービスアカウントのことです。

通常、Google Cloud サービスはプロジェクトごとにサービスエージェントを 1 つだけ持っています。

また、組織レベルで作成されるサービスエージェントもあります。

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

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

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

サービスエージェントとサービスアカウントは別物ではなく、サービスエージェントはサービスアカウントの一種です。サービスアカウントの方が広い概念と言えます。

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

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

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

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

Compute Engine (GCE)

概要

あるプロジェクトで 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) による暗号化を設定する際に関係します。以下のスクリーンショットは、永続ディスクの暗号化方式を CMEK での暗号化にするよう選択したときのメッセージです。

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

ここで権限を持たせるのは、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 (GCS)

概要

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 Functions を起動し、後処理を実装する際などに用いられます。

Cloud Functions を「Cloud Storage トリガの Cloud Functions」という形で実装することがありますが、バックエンドではこの 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

前述の表 3 は書き込み ID と呼ばれるサービスアカウント (サービスエージェント) です。

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

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

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

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

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

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

blog.g-gen.co.jp

Looker Studio (旧称データポータル)

概要

Google Cloud の無償 BI ツールである Looker Studio (旧称データポータル) にもサービスエージェントが存在します。サービスエージェントの名称は以下です。

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

サービスエージェント名は https://datastudio.google.com/serviceAgentHelp にアクセスすることでも確認可能です。

用途

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

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

Google Cloud 上のリソースをデータソースとして扱う際には認証が必要です。Looker Studio では以下のいずれかの方法で認証させることができます。

ダッシュボードのオーナー (作成者) の Google アカウントの権限で認証
ダッシュボードの閲覧者の Google アカウントの権限で認証
サービスアカウントの権限で認証

上記のうち 3. では、データソースへの認証にサービスアカウントを用います。これであれば、利用者にはダッシュボードの閲覧権限だけを与えるだけでよく、データソースへのアクセスはサービスアカウントの権限で自動的に行われます。

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

サービスアカウント自体は、独自に作成してデータソースへのアクセス権限 (BigQuery 閲覧者等) を付与しておきます。

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

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