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

この動作をオーバーライドしない限り、Cloud Build では、ユーザーに代わってビルドを実行する Cloud Build サービス アカウントが自動的に選択されます。 このデフォルトのサービス アカウントには、プロジェクト内の Cloud Storage バケットへのアクセスなど、ユースケースに対して必要以上に幅広い権限が付与されている場合があります。

Cloud Build が新しいプロジェクトでサービス アカウントを使用する際のデフォルトの動作は、2024 年 5 月と 6 月に数週間にわたって変更されました。これらの変更により、今後のお客様のデフォルト セキュリティ対策が改善されます。これらの変更をオプトアウトするには、組織のポリシーの制約を構成します。

この変更前、Cloud Build は Cloud Build 固有のサービス アカウントをデフォルトとして使用していました。現在このサービス アカウントは、Cloud Build の従来のサービス アカウントと呼ばれています。

この変更後、Cloud Build はデフォルトのサービス アカウントとして Compute Engine のデフォルトのサービス アカウントを使用します。

プロジェクトへの影響は、組織に属しているかどうかによって異なります。

  • 組織のないプロジェクト。変更後にプロジェクトで最初のビルドを実行すると、Cloud Build API または Google Cloud CLI を使用して送信されるビルドには、デフォルトで Compute Engine サービス アカウントが使用されます。これらのプロジェクトでは、Cloud Build の従来のサービス アカウントを使用するオプションは使用できませんが、ユーザー指定のサービス アカウントを使用できます。

  • 組織を含むプロジェクト。変更後にプロジェクトで最初のビルドを実行すると、Cloud Build API または Google Cloud CLI を使用して送信されるビルドには、デフォルトで Compute Engine サービス アカウントが使用されます。ユーザー指定のサービス アカウントを使用するか、組織で Cloud Build サービス アカウントを有効にすることで、変更をオプトアウトできます。

  • 組織のない既存のプロジェクト。変更前にプロジェクトで最初のビルドを実行した場合、そのプロジェクトでは、すべてのビルドで Cloud Build の従来のサービス アカウントがデフォルトで使用され、以前の動作が引き続き使用されます。Compute Engine サービス アカウントを選択するか、独自のサービス アカウントを作成することで、ユーザー指定のサービス アカウントを引き続き使用できます。

  • 組織に既存のプロジェクトがある。変更前にプロジェクトで最初のビルドを実行した場合は、従来の Cloud Build サービス アカウントがデフォルトで使用され、以前の動作が引き続き使用されます。ユーザー指定のサービス アカウントを引き続き使用することもできます。

  • トリガー。プロジェクトのデフォルトのサービス アカウントが Cloud Build の従来のサービス アカウントである場合を除き、トリガーを作成または更新するときにサービス アカウントを指定する必要があります。

  • Cloud Build サービス アカウント名: Cloud Build サービス アカウントは、Cloud Build の従来のサービス アカウントと呼ばれます。

必要なご対応について

組織に属している場合は、選択した制約で組織のポリシーを設定することで、すべてのプロジェクトの動作を構成できます。

組織のポリシーの次のブール型制約を設定すると、これらの変更を無効にできます。

  • 未適用: constraints/cloudbuild.disableCreateDefaultServiceAccount
  • 未適用: constraints/cloudbuild.useComputeServiceAccount
  • 適用済み: constraints/cloudbuild.useBuildServiceAccount

組織のポリシーを調整できない、または調整したくない場合で、変更後に Cloud Build API を有効にする場合は、Compute Engine のデフォルトのサービス アカウントまたはユーザーが作成したサービス アカウントに、ビルドに対する十分な権限があることを検証してください。特に、ビルドを送信するユーザーには、サービス アカウントに対する iam.serviceAccounts.actAs 権限が必要です。

新しい組織のポリシーの制約

Cloud Build では、次の構成を行うための新しい組織のポリシーのブール値制約が導入されています。

  • Cloud Build の従来のサービス アカウントを使用するための機能。
  • 組織内のすべてのプロジェクトのデフォルトのサービス アカウント。

組織のポリシーを変更するには、 Google Cloud コンソールまたは Google Cloud CLI を使用します。

  • Google Cloud コンソール: 変更する制約を選択し、Google Cloud コンソールで [適用] オプションを [オン] または [オフ] に設定します。

  • Google Cloud CLI: Google Cloud CLI で制約の適用を構成します。

組織のポリシーの詳細については、組織ポリシー サービスの概要をご覧ください。

Cloud Build の従来のサービス アカウントの可用性を構成する

Cloud Build API を有効にするときに Cloud Build の従来のサービス アカウントの可用性を構成するため、Cloud Build には次のブール値ポリシー制約が導入されます。

  • 未適用: constraints/cloudbuild.disableCreateDefaultServiceAccount。新しいプロジェクトで Cloud Build の従来のサービス アカウントを使用できます。

  • 適用済み: constraints/cloudbuild.disableCreateDefaultServiceAccount。新しいプロジェクトで Cloud Build の従来のサービス アカウントの使用を無効にします。これは制約のデフォルト値です。

この制約は、変更のロールアウト後に最初のビルドを実行するプロジェクトにのみ影響します。ポリシー制約を適用しない場合、その構成が有効になっているときに最初のビルドを実行するすべてのプロジェクトで、変更が永続的に適用されます。サービス アカウントが以前に使用されていたプロジェクトでは、Cloud Build の従来の サービス アカウントの可用性をオフにすることはできません。ただし、サービス アカウントが使用可能な場合でも、次のセクションで説明するように、組織内のユーザーがサービス アカウントを使用できないようにすることができます。

すべての組織のポリシーや制約と同様に、これらのポリシーは組織レベルまたはプロジェクト レベルで設定できます。

組織のデフォルト サービス アカウントを構成する

組織で使用されるデフォルトのサービス アカウントを構成するために、Cloud Build では 2 つの新しいポリシーのブール型制約が導入されています。

これらのポリシーは個別に構成できますが、次のシナリオで適用ルールを組み合わせると最も効果的です。

  • 最も安全なオプション: 手動で送信されたビルドとトリガーされたビルドの両方にユーザー指定のサービス アカウントを使用します。これを行うには、組織のポリシーに次の制約を設定します。

    • 未適用: constraints/cloudbuild.useBuildServiceAccount
    • 未適用: constraints/cloudbuild.useComputeServiceAccount

  • Compute Engine のデフォルトのサービス アカウント: 手動で送信されたビルドとトリガーされたビルドの両方に Compute Engine のデフォルトのサービス アカウントを使用するには、組織のポリシーで次の制約を設定します。

    • 未適用: constraints/cloudbuild.useBuildServiceAccount
    • 適用済み: constraints/cloudbuild.useComputeServiceAccount

  • Cloud Build の従来のサービス アカウント: 関連するセキュリティのトレードオフを理解している場合は、組織のポリシーに次の制約を設定します。

    • 未適用: constraints/cloudbuild.disableCreateDefaultServiceAccount
    • 未適用: constraints/cloudbuild.useComputeServiceAccount
    • 適用済み: constraints/cloudbuild.useBuildServiceAccount

  • 以前のサービス アカウントと Compute Engine のデフォルトのサービス アカウント: 変更前に Cloud Build API を有効にしたプロジェクトでは、引き続き Cloud Build の以前のサービス アカウントを使用し、新しいプロジェクトでは Compute Engine のデフォルトのサービス アカウントの使用を開始します。関連するセキュリティのトレードオフを理解している場合は、組織のポリシーに次の制約を設定します。

    • 適用済み: constraints/cloudbuild.disableCreateDefaultServiceAccount
    • 適用済み: constraints/cloudbuild.useComputeServiceAccount
    • 適用済み: constraints/cloudbuild.useBuildServiceAccount

IAM ロールのガイドライン

iam.automaticIamGrantsForDefaultServiceAccounts 組織のポリシーにより、特定のデフォルトのサービス アカウントに作成時に編集者ロール（roles/editor）が付与されなくなります。このポリシーは、2024 年 5 月 3 日の時点で組織で有効になっており、2024 年 5 月 3 日以降に作成された Compute Engine と App Engine のデフォルトのサービス アカウントに適用されます。編集者ロールは非常に広範囲に及び、ほとんどのユースケースで必要な権限よりも多くの権限が付与されるため、このポリシーを有効にしておくことをおすすめします。

この組織のポリシーは、Cloud Build の従来のサービス アカウントには適用されません。このサービス アカウントには、デフォルトで編集者のロールが付与されていないためです。ただし、Cloud Build の従来のサービス アカウントには、デフォルトで Cloud Build サービス アカウントのロール（roles/cloudbuild.builds.builder）が付与されており、このロールにも広範な権限が付与されています。Cloud Build の以前のサービス アカウントを使用する場合は、Cloud Build サービス アカウントのロールがユースケースに必要かどうか、または権限の少ないロールに置き換えることができるかどうかを確認することをおすすめします。

詳細については、IAM サービス アカウントの使用を制限すると IAM を安全に使用するをご覧ください。

プロジェクトの現在のデフォルト サービス アカウントを取得する

Cloud Build がプロジェクトのデフォルトとして使用しているサービス アカウントを特定するには、Google Cloud CLI または Cloud Build API を使用します。

gcloud CLI

次のコマンドを実行して、現在のプロジェクトのデフォルトのサービス アカウントを取得します。

gcloud builds get-default-service-account

Cloud Build API

cURLを使用して Cloud Build API を呼び出します。

curl -X GET -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     https://cloudbuild.googleapis.com/v1/projects/PROJECT_ID/locations/REGION/defaultServiceAccount

プレースホルダの値を次のように置き換えます。