G-gen の藤岡です。これまでデフォルトの Cloud Build サービスアカウントとして使われていた <PROJECT_NUMBER>@cloudbuild.gserviceaccount.com の仕様が2024年4月29日から変更されます。当記事では、変更点とその影響について詳しく解説します。

この変更は2024年1月16日に発表されたばかりであり、今後より詳細な情報が出てくる可能性がありますので、新しい発表があり次第、随時更新します。

前提知識

Cloud Build とは

Cloud Build とは、ソースコードのコンパイル、テストの実行、アプリケーションのデプロイなどを行う CI/CD サービスです。また、コードの変更をトリガーにビルドを起動することもできます。

Cloud Run や Google Kubernetes Engine（GKE）など、Google Cloud の他のサービスへのデプロイでも Cloud Build が使われます。Cloud Build の履歴画面から過去のビルド履歴を確認できます。利用者側で Cloud Build を使っていると思っていなくても、別のサービスの裏側で使われている場合もあります。

デフォルトの Cloud Build サービスアカウントとは

デフォルトの Cloud Build サービスアカウントは <PROJECT_NUMBER>@cloudbuild.gserviceaccount.com です。これは Cloud Build API を有効にすると自動で作られます。

このデフォルトの Cloud Build サービスアカウントには、「Cloud Build サービスアカウント (roles/cloudbuild.builds.builder)」ロールが自動で付与されます。このロールには、Artifact Registry へのイメージのプッシュや Cloud Logging へのログ書き込みなど、ビルドで必要な権限が包含されています。明示的にサービスアカウントを指定しない場合、このデフォルトの Cloud Build サービスアカウントが裏側で動いています。

Cloud Build API を有効化すると、サービスアカウントのうちの 1 つであるサービスエージェント (service-<PROJECT_NUMBER>@gcp-sa-cloudbuild.iam.gserviceaccount.com) も自動作成されますが、今回の仕様変更にサービスエージェントは含まれないため、当記事では説明を割愛します。

サービスエージェントについては以下の記事をご参照ください。 blog.g-gen.co.jp

参考: Cloud Build サービスアカウント

デフォルトの Compute Engine サービスアカウントとは

デフォルトの Compute Engine サービスアカウントは <PROJECT_NUMBER>-compute@developer.gserviceaccount.com です。これは Compute Engine API を有効にすると自動で作られます。

このデフォルトの Compute Engine サービスアカウントには「編集者 (roles/editor)」ロールが自動で付与されます。この編集者ロールは広範囲な権限を持っているため、実運用での利用は非推奨です。

変更点

適用条件

デフォルトの Cloud Build サービスアカウントの仕様変更は、2024年4月29日以降に Cloud Build API を有効にしたプロジェクトに対して適用されます。これはプロジェクトの作成日ではなく、API を有効にした日に基づきます。

つまり、2024年4月28日までに Cloud Build API を有効化しているプロジェクトではこれまでの仕様と変わらず利用できるため、対応は不要です。

参考: Cloud Build Service Account Change

内容

変更点は以下の 3 つです。

No.	概要	変更前	変更後	ワークアラウンド (対処法)
1	サービスアカウントの名称が変更される	Cloud Build サービスアカウント	従来の Cloud Build サービスアカウント	-
2	デフォルトでビルド時に使われるサービスアカウントが変更される	Cloud Build サービスアカウント	Compute Engine サービスアカウント	Cloud Build 用にサービスアカウントを作成し、適切な権限を付与する
3	ビルドトリガー作成時にサービスアカウント指定が必須になる	指定しない場合は、Cloud Build サービスアカウントが自動選択されていた	サービスアカウントの明示的な指定が必須	ビルドトリガー作成時にサービスアカウントを明示的に指定する

影響範囲の例

Terraform など IaC ツールのテンプレート更新が必要

Terraform などの IaC ツールを使ってクラウド環境の払い出し（プロジェクトの新規作成）をする運用をしている場合、今回の仕様変更により、同じテンプレートが使えなくなる場合があります。

IaC ツールにより、定期的に「プロジェクトの新規作成」「Cloud Build API の有効化」を自動的に行い、その後 Cloud Build でのビルド（Cloud Functions 関数のデプロイを含む）を行う環境の場合、2024年4月29日以降に同じテンプレートでビルドを実行すると、前述の変更点 No. 2と No. 3に該当するため、権限不足などのエラーが発生する可能性があります。

特定の組織ポリシー適用下でビルドが失敗する

Disable Automatic IAM Grants for Default Service Accounts

Disable Automatic IAM Grants for Default Service Accounts (constraints/iam.automaticIamGrantsForDefaultServiceAccounts) は、Compute Engine API を有効にすると自動で作られるデフォルトの Compute Engine サービスアカウントへの編集者（roles/editor）ロール付与を無効にする制約です。

この制約下では、前述の変更点 No. 2の影響を受けます。Cloud Build で使われるサービスアカウントを指定しない場合、これまではデフォルトの Cloud Build サービスアカウントが使われ、必要な権限はユーザー側で意識する必要はありませんでした。しかしこの制約下では、デフォルトの Compute Engine サービスアカウントは何の権限も持たないため、ビルドが失敗するようになります。

組織ポリシーに関する詳細は以下の記事をご参照ください。

blog.g-gen.co.jp

参考: デフォルトのサービスアカウントへの自動的なロール付与を無効にする

また、この制約を使っていないとしても、デフォルト Compute Engine サービスアカウントのプロジェクトレベルでの編集者（roles/editor）ロールを削除している場合で、かつビルドに必要な権限が不足している場合は、ビルドが権限不足エラーになります。

VPC Service Controls 境界で API コールが拒否される

VPC Service Controls の内向きポリシー (Ingress rules) や外向きポリシー (Egress rules) でデフォルトの Cloud Build サービスアカウントを FROM 属性に指定している場合、前述の変更点 No. 2の影響を受けます。

ビルド時に明示的にサービスアカウントを指定しない場合、デフォルトの Compute Engine サービスアカウントが使われるようになるため、既存のルールではアクセスレベル違反になります。

VPC Service Controls に関する詳細は以下の記事をご参照ください。 blog.g-gen.co.jp

対処法

組織のポリシーによる対策

本仕様変更後に Cloud Build API を有効化するプロジェクトで、現在の仕様を変更したくない場合は、組織ポリシー「Disable Create Default Service Account (Cloud Build) (constraints/cloudbuild.disableCreateDefaultServiceAccount)」の制約をオフにします。

この制約をオンにすると、Cloud Build API を有効化してもデフォルトの Cloud Build サービスアカウント (<PROJECT_NUMBER>@cloudbuild.gserviceaccount.com) は作られません。

This boolean constraint, when enforced, disallows the Cloud Build service account from being created on demand.

2024年1月22日時点ではデフォルトで「適用済み」つまり、オンの状態になっています。編集画面からオフにすると以下のように未適用となります。

Disable Create Default Service Account (Cloud Build) 制約の画面

ドキュメントの記述によると、「Disable Create Default Service Account (Cloud Build)」の制約を明示的にオフにした場合、2024年4月29日以降も、これまでどおり Cloud Build API を有効にした際にデフォルトの Cloud Build サービスアカウント (<PROJECT_NUMBER>@cloudbuild.gserviceaccount.com) が自動作成されます。しかしその場合に、前述の変更点 No. 2 と No. 3 は従来通りの挙動となるのか、あるいは仕様変更後の挙動になるのかは、2024年1月22日現在ではわかっていません。そのため、適切な検証と対策を行ってください。

参考: New organization policy

適切な設定変更を行う

根本対処としては、以下のように、影響範囲に応じた対処を行います。以下の記載は例であり、実際には影響範囲を適切に考慮して対策を行ってください。

	影響範囲	ワークアラウンド (対処法)
A	Terraform など IaC ツールのテンプレート更新が必要	Compute Engine サービスアカウントへの権限付与、VPC Service Controls 境界の設定変更など、テンプレートを更新する
B	特定の組織ポリシー適用下でビルドが失敗する	Cloud Build によるビルド時に明示的にサービスアカウントを指定する。または、Compute Engine サービスアカウントに適切な権限を付与する
C	VPC Service Controls で弾かれる	VPC Service Controls 境界の設定を変更する

Bについては、ユーザーが明示的に Cloud Build を使ってビルドを行う場合に加えて、以下のような場合における影響が考えられます。

Cloud Functions のデプロイ（デプロイ時に Cloud Build が使われる）
Cloud Composer の環境作成（環境作成時に Cloud Build が使われる）

前者の Cloud Functions のデプロイにおいては、デフォルト Compute Engine サービスアカウントが使用されるようになります。デフォルト Compute Engine サービスアカウントに適切な権限を付与するか、以下のドキュメントを参考にして、デプロイ時にビルド用サービスアカウントを明示的に指定します。

参考 : Custom Service Account for Cloud Build

後者の Cloud Composer の環境作成においては、環境（environment）にアタッチするサービスアカウントがビルド時にも使用されるようになります（明示的に指定しない場合、デフォルト Compute Engine サービスアカウント）。環境用のサービスアカウントに明示的にカスタムサービスアカウントを指定している場合、そのサービスアカウントは自分自身に対して「サービスアカウントユーザー（roles/iam.serviceAccountUser）」を付与する必要があります。