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

プロジェクトの設定によっては、Cloud Build が Cloud Build の従来のサービス アカウントまたは Compute Engine のデフォルトのサービス アカウントを使用して、ユーザーに代わってビルドを実行することがあります。Cloud Build の従来のサービス アカウントのメールアドレスは [PROJECT_NUMBER]@cloudbuild.gserviceaccount.com であり、Compute Engine のデフォルト サービス アカウントのメールアドレスは [PROJECT_NUMBER]-compute@developer.gserviceaccount.com です。デフォルトのサービス アカウントには、ユースケースに対して必要以上に幅広い権限が付与されている場合があります。最小権限の原則に従うことで、セキュリティ体制を強化できます。この原則に基づき、ユーザーの代理でビルドを実行する独自のサービス アカウントを作成することをおすすめします。これにより、構成ミスや悪意のあるユーザーによる潜在的な影響が軽減されます。

このページでは、Cloud Build の従来のサービス アカウントにデフォルトで付与されるすべての権限について説明します。

Compute Engine のデフォルトのサービス アカウントについては、Compute Engine のデフォルトのサービス アカウントをご覧ください。

Cloud Build のデフォルトのサービス アカウントに権限を付与する、または権限を取り消す方法については、Cloud Build のデフォルトのサービス アカウントのアクセス権を構成するをご覧ください。

Cloud Build の従来のサービス アカウントのデフォルト権限

プロジェクトの設定で Cloud Build の従来のサービス アカウントの使用が許可されている場合、プロジェクト内のリソースに対する Cloud Build サービス アカウントのロールが付与されます。このロールには、ビルドの更新やログの書き込みを行うことができるなどの、いくつかの権限が含まれます。サービス アカウントは、ビルドの実行時にアクションを実行するために必要な場合にのみ、これらの権限を使用します。たとえば、サービス アカウントは artifactregistry.dockerimages.get 権限を使用して Container Registry から Docker イメージを取得します。ただし、これは、このように取得するようにビルドで構成されている場合に限られます。ビルドプロセスの一環としてアクションを実行する予定がない場合は、セキュリティに関する最小権限の原則に準拠するために、サービス アカウントから対応する権限を取り消すことをおすすめします。

次の表に、Cloud Build サービス アカウントのロールに含まれる権限と、Cloud Build レガシー サービス アカウントがこれらの権限を使用する目的を示します。

権限 説明 権限の目的
cloudbuild.builds.create ビルドとトリガーを作成できる 必要事項:
  • ビルドトリガーを使用する
  • ビルドの作成、一覧表示、取得、キャンセルを行う
cloudbuild.builds.update ビルドとトリガーを更新できる
cloudbuild.builds.list ビルドとトリガーを一覧表示できる
cloudbuild.builds.get ビルドとトリガーを取得できる
cloudbuild.workerpools.use プライベート プールを使用する プライベート プールでビルドを実行するために必要。
logging.logEntries.create ログを書き込む Cloud Logging でのビルドログの作成と一覧表示に必要。
logging.logEntries.list ログを一覧表示できる
logging.views.access ログを表示できる
pubsub.topics.create Pub/Sub トピックを作成する ビルドの更新を Pub/Sub に push するときに必要
pubsub.topics.publish Pub/Sub に公開する
remotebuildexecution.blobs.get ビルドを承認または拒否するためのアクセス権を取得できる 保留中のビルドを承認または拒否するために必要
resourcemanager.projects.get プロジェクト情報を取得できる
resourcemanager.projects.list プロジェクトを一覧表示する
source.repos.get Cloud Source Repositories のリポジトリからソースコードを読み取る 必要事項:
  • Bitbucket トリガーと Cloud Source Repositories トリガーを使用する
  • Cloud Source Repositories からソースコードを pull する
source.repos.list Cloud Source Repositories のリポジトリを一覧表示する
storage.buckets.create Cloud Storage バケットを作成できる 必要事項:
  • Container Registry でイメージを保存、取得する（非推奨）。
  • Cloud Storage にアーティファクトを保存、取得する。
  • gcloud builds submit で手動でビルドを送信する
  • ビルドログをユーザーが作成したログバケットに保存する
storage.buckets.get Cloud Storage バケットを取得する
storage.buckets.list Cloud Storage バケットを一覧表示する
storage.objects.list Cloud Storage オブジェクトを一覧表示する
storage.objects.update Cloud Storage オブジェクトを更新する
storage.objects.create Cloud Storage オブジェクトを書き込む
storage.objects.delete Cloud Storage オブジェクトを削除する
storage.objects.get Cloud Storage オブジェクトを読み取る
artifactregistry.repositories.uploadArtifacts Artifact Registry のリポジトリにアーティファクトをアップロードする Artifact Registry のアーティファクトの管理に必要
artifactregistry.repositories.downloadArtifacts Artifact Registry のリポジトリからアーティファクトをダウンロードする
artifactregistry.aptartifacts.create Apt アーティファクトを Artifact Registry にアップロードする
artifactregistry.dockerimages.get Artifact Registry から Docker イメージを取得する
artifactregistry.dockerimages.list Artifact Registry 内の Docker イメージを一覧表示する
artifactregistry.kfpartifacts.create KFP アーティファクトを Artifact Registry にアップロードする
artifactregistry.locations.get Artifact Registry にあるリソースのロケーションに関する情報を取得する
artifactregistry.locations.list Artifact Registry でサポートされるロケーションを一覧表示する
artifactregistry.mavenartifacts.get Artifact Registry から Maven パッケージを取得する
artifactregistry.mavenartifacts.list Artifact Registry から Maven パッケージを一覧表示する
artifactregistry.npmpackages.get Artifact Registry から npm パッケージを取得する
artifactregistry.npmpackages.list Artifact Registry から npm パッケージを一覧表示する
artifactregistry.projectsettings.get Artifact Registry からプロジェクト設定を取得する
artifactregistry.pythonpackages.get Artifact Registry から Python パッケージを取得する
artifactregistry.pythonpackages.list Artifact Registry から Python パッケージを一覧表示する
artifactregistry.yumartifacts.create Yum アーティファクトを Artifact Registry にアップロードする
artifactregistry.repositories.createOnPush プロジェクトでイメージが gcr.io ホスト名に初めて push されたときに、Artifact Registry で gcr.io リポジトリを作成できます。
artifactregistry.repositories.get Artifact Registry からリポジトリを取得する
artifactregistry.repositories.list Artifact Registry でリポジトリを一覧表示する
artifactregistry.repositories.listEffectiveTags Artifact Registry にあるアーティファクトのタグを一覧表示する Artifact Registry にあるアーティファクトのタグを管理するために必要
artifactregistry.repositories.listTagBindings Artifact Registry にあるアーティファクトのタグ バインディング情報を一覧表示する
artifactregistry.tags.create Artifact Registry でタグを作成する
artifactregistry.tags.get Artifact Registry からタグを取得する
artifactregistry.tags.list Artifact Registry 内のタグを一覧表示する
artifactregistry.tags.update Artifact Registry でタグを更新する
artifactregistry.versions.list Artifact Registry 内のバージョンを一覧表示する
artifactregistry.versions.get Artifact Registry からバージョンを取得する
containeranalysis.occurrences.create Artifact Analysis の実行回数を作成する これらの権限は、Cloud Build サービス アカウントでは使用されませんが、下位互換性のために含まれています。
containeranalysis.occurrences.delete Artifact Analysis の実行回数を削除する
containeranalysis.occurrences.get Artifact Analysis の実行回数を取得する
containeranalysis.occurrences.list Artifact Analysis の実行回数を一覧表示する
containeranalysis.occurrences.update Artifact Analysis の実行回数を更新する

ビルドトリガー

ビルドトリガーを作成するときに、ビルドの実行に使用するサービス アカウントを選択する必要があります。各トリガーに異なるサービス アカウントを構成できます。唯一の例外は、プロジェクトで Cloud Build の従来のサービス アカウントが有効になっている場合です。この場合、他のアカウントが選択されていない場合、ビルドトリガーはデフォルトで従来のサービス アカウントを使用します。

トリガーへのユーザー アクセス

トリガーへのユーザー アクセスは、トリガーに構成されているサービス アカウントの種類によって異なります。

  • Cloud Build の従来のサービス アカウント（有効な場合）: Cloud Build 編集者のロールを持つユーザーは、トリガーを作成して直接実行できます。たとえば、ユーザーはトリガーを手動で実行できます。トリガーが Cloud Build の従来のサービス アカウントを使用している限り、Cloud Build 編集者のロールを持つユーザーは、トリガーを更新できます。

  • ユーザー指定のサービス アカウントまたは Compute Engine のデフォルトのサービス アカウント: Cloud Build 編集者のロールを持ち、iam.serviceAccounts.actAs 権限を持つユーザーは、トリガーを作成して直接実行できます。たとえば、ユーザーはトリガーを手動で実行できます。 Cloud Build 編集者のロールを持つユーザーは、トリガーに指定された、以前に構成されたサービス アカウントと新しいサービス アカウントの両方に対する iam.serviceAccounts.actAs 権限があれば、トリガーを更新できます。ユーザーにこの権限を付与するには、サービス アカウント ユーザーロール（roles/iam.serviceAccountUser）など、権限を含む事前定義ロールをユーザーに付与します。または、iam.serviceAccounts.actAs 権限を持つカスタム IAM ロールを作成し、そのロールをユーザーに付与することもできます。サービス アカウントの権限の詳細については、サービス アカウントの認証用のロールをご覧ください。

トリガーのビルド時の権限

ビルドトリガー用に構成されたサービスアカウントでは、ビルドを呼び出すトリガーを使用するユーザーに、ビルド時の昇格した権限を付与できます。これは、従来のサービス アカウントとユーザー指定のサービス アカウントの両方に適用されます。ビルドトリガーを使用する場合は、次のセキュリティ上の影響に注意してください。

  • Google Cloud プロジェクトへのアクセス権はないが、プロジェクト内のビルドトリガーに関連付けられたリポジトリへの書き込みアクセス権があるユーザーは、ビルドされるコードを変更する権限を持ちます。 たとえば、接続されたリポジトリに新しいソースコードを push すると、ユーザーは間接的にトリガーを呼び出すことができます。

  • さらに、GitHub pull リクエスト トリガーを使用している場合は、リポジトリへの読み取りアクセス権を持つすべてのユーザーが pull リクエストを送信できます。これにより、pull リクエスト内のコードの変更を含むビルドがトリガーされる可能性が生じます。この動作を無効にするには、GitHub の pull リクエスト トリガーを作成するときに [コメント制御] オプションを選択します。このオプションを選択すると、リポジトリ所有者または共同編集者が /gcbrun にコメントした場合にのみビルドが開始されます。GitHub トリガーでコメント制御を使用する方法については、GitHub トリガーの作成をご覧ください。

制限事項

ID トークンを使用してサービス間で認証する必要がある場合は、ユーザー指定のサービス アカウントを使用してビルドを実行する必要があります。Cloud Build の従来のサービス アカウントを使用して ID トークンを生成することはできません。

たとえば、Cloud Run Functions、Cloud Run、App Engine などのサーバーレス プラットフォーム アプリケーションを使用していて、Cloud Build からアプリケーションを呼び出す場合は、サービス間の認証に必要な権限を使用して構成されたユーザー指定のサービス アカウントが必要です。

手順については、サービス間アクセスを承認するをご覧ください。

次のステップ