【Breaking Change】Compute Engineのブートディスク操作に iam.serviceAccounts.actAs 権限が必須化されました

はじめに

こんにちは。
クラウド事業本部コンサルティング部の渡邉です。

2026年3月19日、Compute EngineにおいてBreaking Changeが発表されました。サービスアカウントがアタッチされたインスタンスのブートディスクに対する各種操作で、iam.serviceAccounts.actAs 権限が必須となりました。

https://docs.cloud.google.com/release-notes#March_19_2026

この変更は、スナップショット作成やマシンイメージ作成といった日常的なバックアップ運用にも影響する可能性があります。本記事では、変更の詳細と影響範囲、そして必要な対応を確認していきます。

変更の概要

何が変わったのか

サービスアカウントがアタッチされたCompute Engineインスタンスのブートディスクに対する以下の操作で、そのサービスアカウントに対する iam.serviceAccounts.actAs 権限が必要になりました。

影響を受けるケース・受けないケース

対応不要なケース

以下の両方のロールをプロジェクトレベルで既に持っている場合は、対応は不要です。

• Compute Instance Admin (v1)（roles/compute.instanceAdmin.v1）
• Service Account User (v1)（roles/iam.serviceAccountUser）

roles/iam.serviceAccountUser には iam.serviceAccounts.actAs 権限が含まれているため、このロールが付与されていれば今回の変更による影響はありません。

スナップショットスケジュールを使用して定期的にブートディスクのバックアップを取得している場合も、対応は不要です。

スナップショットスケジュールによる自動スナップショット作成は、Google Cloudが管理するCompute Engine Service Agent（service-PROJECT_NUMBER@compute-system.iam.gserviceaccount.com）が実行します。このService Agentには roles/compute.serviceAgent ロールが付与されており、このロールには iam.serviceAccounts.actAs 権限が含まれているためです。

そのため、スナップショットスケジュールの自動実行は今回の変更の影響を受けません。

対応が必要なケース

以下のようなケースでは対応が必要になります。

• roles/compute.storageAdmin のみでスナップショットやイメージを管理している場合
• カスタムIAMロールを使用しており、iam.serviceAccounts.actAs が含まれていない場合
• CI/CDパイプラインのサービスアカウントが最小権限の原則でディスク操作権限のみ持っている場合（例：CI/CDでブートディスクのスナップショットを取得してバックアップを行っている場合、そのCI/CDが使用するサービスアカウントに対して、インスタンスにアタッチされたサービスアカウントへの iam.serviceAccounts.actAs 権限が必要）
• サードパーティのバックアップツールなどがカスタムロールで動作している場合

カスタムロールを利用して最小権限での権限管理を運用している場合は、iam.serviceAccounts.actAsの権限をカスタムロールに追加する必要があります。

対応方法

Service Account Userロールの付与

最もシンプルな対応は、対象ユーザーまたはサービスアカウントに roles/iam.serviceAccountUser ロールを付与することです。

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="user:USER_EMAIL" \
  --role="roles/iam.serviceAccountUser"

ただし、このロールはプロジェクト内のすべてのサービスアカウントに対して iam.serviceAccounts.actAs を許可するため、最小権限の原則に反する場合があります。

特定のサービスアカウントに対する権限付与

特定のサービスアカウントに対してのみ iam.serviceAccounts.actAs を許可する場合は、サービスアカウントレベルでロールを付与します。

gcloud iam service-accounts add-iam-policy-binding \
  SA_EMAIL \
  --member="user:USER_EMAIL" \
  --role="roles/iam.serviceAccountUser"

この方法であれば、指定したサービスアカウントに対してのみ権限が付与されるため、より安全で推奨されます。

カスタムロールへの権限追加

既存のカスタムロールを使用している場合は、iam.serviceAccounts.actAs 権限を追加します。
先ほどの対応が必要なケースで記載したカスタムロールを運用しているユーザはこちらの対応が必要になります。

gcloud iam roles update CUSTOM_ROLE_ID \
  --project=PROJECT_ID \
  --add-permissions="iam.serviceAccounts.actAs"

影響の確認方法

自分のIAM権限に iam.serviceAccounts.actAs が含まれているかを確認するには、以下のコマンドが便利です。

# 特定のサービスアカウントに対するactAs権限の有無を確認
gcloud iam service-accounts get-iam-policy SA_EMAIL \
  --format="table(bindings.role, bindings.members)"

また、プロジェクトレベルのIAMポリシーで roles/iam.serviceAccountUser が付与されているかを確認します。

gcloud projects get-iam-policy PROJECT_ID \
  --flatten="bindings[].members" \
  --filter="bindings.role:roles/iam.serviceAccountUser" \
  --format="table(bindings.members)"

最後に

2026年3月19日に発表された、Compute Engineのブートディスク操作における iam.serviceAccounts.actAs 権限の必須化（Breaking Change）について紹介しました。

Compute Instance Admin (v1) + Service Account User (v1) を既に持っている場合や、スナップショットスケジュールによる自動バックアップを利用している場合は対応不要ですが、CI/CDパイプラインやバックアップ自動化で最小権限のカスタムロールを使用している環境では、権限不足によるエラーが発生する可能性がありますので、早めにIAMポリシーを確認することをお勧めします。

この記事が誰かの助けになれば幸いです。

以上、クラウド事業本部コンサルティング部の渡邉でした！