G-gen の藤岡です。これまでデフォルトの Cloud Build サービスアカウントとして使われていた <PROJECT_NUMBER>@cloudbuild.gserviceaccount.com
の仕様が2024年4月29日から変更されます。当記事では、変更点とその影響について詳しく解説します。
注意点
本変更は、2024年5月〜6月にかけて順次展開されます。
最新の仕様は、必ず以下の Google Cloud の公式ドキュメントをご確認ください。
またリンク先の公式ドキュメントは英語版にしないと最新情報が反映されていない場合がありますのでご注意ください。
前提知識
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
デフォルトの 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 を有効化しているプロジェクトではこれまでの仕様と変わらず利用できるため、対応は不要です。
内容
変更点は以下の 3 つです。
No. | 概要 | 変更前 | 変更後 | ワークアラウンド (対処法) |
---|---|---|---|---|
1 | サービスアカウントの名称が変更される | Cloud Build サービスアカウント | 従来の Cloud Build サービスアカウント(Legacy Cloud Build Service Account) | - |
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 サービスアカウントは何の権限も持たないため、ビルドが失敗するようになります。
組織ポリシーに関する詳細は以下の記事をご参照ください。
また、この制約を使っていないとしても、デフォルト 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.
(日本語訳)このブール型制約を適用すると、従来の Cloud Build サービス アカウントを作成できなくなります。
デフォルトで「適用済み」つまり、オンの状態になっています。編集画面からオフにすると以下のように未適用となります。
ドキュメントの記述によると、「Disable Create Default Service Account (Cloud Build)」の制約を明示的にオフにした場合、2024年4月29日以降も、これまでどおり Cloud Build API を有効にした際にデフォルトの Cloud Build サービスアカウント (<PROJECT_NUMBER>@cloudbuild.gserviceaccount.com
) が自動作成され、従来の動作が継続されます。
適切な設定変更を行う
根本対処としては、以下のように、影響範囲に応じた対処を行います。以下の記載は例であり、実際には影響範囲を適切に考慮して対策を行ってください。
影響範囲 | ワークアラウンド (対処法) | |
---|---|---|
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 サービスアカウントに適切な権限を付与するか、以下のドキュメントを参考にして、デプロイ時にビルド用サービスアカウントを明示的に指定します。
後者の Cloud Composer の環境作成においては、環境(environment)にアタッチするサービスアカウントがビルド時にも使用されるようになります(明示的に指定しない場合、デフォルト Compute Engine サービスアカウント)。環境用のサービスアカウントに明示的にカスタムサービスアカウントを指定している場合、そのサービスアカウントは自分自身に対して「サービス アカウント ユーザー (roles/iam.serviceAccountUser
)」を付与する必要があります。
藤岡 里美 (記事一覧)
クラウドソリューション部
数年前までチキン売ったりドレスショップで働いてました!2022年9月 G-gen にジョイン。ハイキューの映画を4回は見に行きたい。
Google Cloud All Certifications Engineer / Google Cloud Partner Top Engineer 2024