デフォルト サービス アカウントとは
サービスアカウントには下記3つの種類が存在します。
- ユーザー管理のサービス アカウント
- デフォルトのサービス アカウント
- Google 管理のサービス アカウント
デフォルトのサービスアカウントは、特定のGoogle Cloud サービスを有効にするときに自動的に作成されるもので、ユーザーで管理できるサービスアカウントになります。
役割としては、自動化されたタスクやAPI呼び出しを行う際に使用され、ユーザーが作成を意識しなくても、Google Cloudのサービスを使えるようにあらかじめ生成してくれるものと理解するとイメージがしやすいかもしれません。
実際に、IAMと管理でCompute Engineのデフォルトのサービスアカウントを確認できます。
今回の変更内容
概要
新しいプロジェクトでデフォルトで使用される Cloud Build サービス アカウントが変更されます。潜在的な問題を回避するには、2024 年 4 月 29 日までに新しい動作をテストするかオプトアウトしてください。
Cloud Buildを有効化した時にデフォルトで作成されるサービスアカウントの仕様が変更されるようです。下記にまとめます。
- 2024年4月29日から、新規プロジェクトでは、Cloud Buildが利用するデフォルトのサービスアカウントが従来のCloud BuildサービスアカウントからCompute Engineサービスアカウントに変更される
- 2024年4月29日より前にCloud Build API を有効にした既存のプロジェクトは、この変更の影響を受けない
- Cloud Buildで新しいビルドトリガーを設定するときには、どのサービスアカウントを使用するかをユーザーが明示的に指定する必要がある
- 組織単位で、これらの変更を受け入れるか、組織ポリシーを調整してオプトアウトすることができる
影響
重要な事項をまとめます。（Compute Engine → GCE、サービスアカウント → SA）
- 現在、Cloud BuildのデフォルトSAに依存してビルドを実行しているかを確認する
- 直接送信されるビルドを実行する場合、GCEのデフォルトSAが使用されため、このアカウントがビルドの実行に十分かどうか検証し、ビルドを実行するユーザーがそのSAで操作を行う権限（iam.serviceAccounts.actAs）を持っていることを確認する必要がある
- 新しいプロジェクトでは、ビルドのトリガーにサービスアカウントを明示的に指定することが必須になりトリガーは、指定されたSAを持たないと実行されなくなる
- ただし、Cloud Buildの従来の動作を維持したい場合、組織ポリシーの設定を変更することで回避できる（後述）
- Cloud Functionsユーザー
- 新しいプロジェクトでは組織ポリシーが適用され、Compute EngineのデフォルトSAが使用される。関数をデプロイするためには、必要な権限が設定されていることを確認する必要がある
- Cloud Composerユーザー
- 新しいプロジェクトでは、デフォルトでCloud Buildの環境サービスアカウントが使用される。カスタムサービスアカウントを使用する場合は、適切なロールが設定されていることを確認する必要がある
対応策
新しい組織ポリシーの導入
constraints/cloudbuild.disableCreateDefaultServiceAccount上記の組織ポリシーのブール制約をオフに設定することで、組織自体で従来のCloud Build サービスアカウントの自動作成を停止し、代わりに自分たちでサービスアカウントを管理する責任を持つ事ができます。
これは新しいCloud Build の変更導入を回避して、既定のCloud Build サービスアカウントが引き続き新しいプロジェクトで作成されるようにするための設定です。（これまで通りの運用）
さらに、未導入なので、コンソールでの確認はまだできません。
まとめ
今回のアップデートは見落としがちな細かな内容かもしれませんが、普段から開発をしている方であれば押さえておきたい変更かもしれません。
今回のソースはこちら
https://cloud.google.com/build/docs/cloud-build-service-account-updates#org-policy
4
