ユーザー指定のサービスアカウントを構成する

Cloud Build の最小権限の原則に従うには、最小限の権限が付与されたサービスアカウントを使用してビルドを実行するように Cloud Build を構成します。このページでは、サービスアカウントを設定する方法について説明します。

サービスアカウントを指定しない場合は、Cloud Build がサービスアカウントを自動的に選択してビルドを実行する場合があります。このサービスアカウントには、プロジェクト内の Cloud Source Repositories や Cloud Storage バケットへのアクセスなど、ユースケースに対して必要以上に幅広い権限が付与されている場合があります。

プロジェクトのセキュリティ体制を強化し、構成ミスや悪意のあるユーザーの潜在的な影響を減らすには、最小権限の原則に従うことをおすすめします。この原則を採用することで、実行するタスクに限られた範囲の権限とロールを各サービスアカウントに割り当てることができます。たとえば、Google Cloud ブログで説明されるように、1 つのサービスアカウントでイメージのビルドと Artifact Registry への push が可能です。

始める前に

Enable the Cloud Build and IAM APIs.
Enable the APIs
このアカウントを使用して認証情報を作成および管理する場合（有効期間の短い認証情報を作成するなど）は、IAM Service Account Credentials API を有効にします。

Enable the API
サービスアカウントを作成します（まだ作成していない場合）。

IAM 権限を付与

ビルドが接続に必要なサービスにアクセスできるようにするには、次のロールと権限を付与する必要があります。

Cloud Build 設定ページを開きます。

Cloud Build 設定ページを開く

[サービスアカウント権限] タブが表示されます。
プルダウンリストから、ロールを変更するサービスアカウントを選択します。
追加するロールのステータスを「有効」に設定します。
ビルドパイプラインに必要なロールがこちらに記載されていない場合は、IAM 構成ページで追加のロールを付与します。

ビルドに必要となる一般的なロールの詳細については、Cloud Build リソースへのアクセスの構成と、Cloud Build IAM のロールと権限の完全版リストをご覧ください。

ビルドログを設定する

ビルド用に独自のサービスアカウントを指定する場合、Cloud Logging またはユーザーが作成した Cloud Storage バケットにビルドログを保存する必要があります。デフォルトのログバケットにログを保存することはできません。

Cloud Storage バケットにログを保存するには、ユーザーが作成したバケットにビルドログを保存するの手順に従います。ログバケットに保持ポリシーを設定していないことを確認します。設定されている場合、Cloud Build がビルドログをバケットに書き込めなくなる可能性があります。
ビルドログを Cloud Logging に保存するには、サービスアカウントにログ書き込み（roles/logging.logWriter）ロールを割り当てます。
ビルドログの保存場所の詳細については、ビルドログの保存場所の選択をご覧ください。

構成ファイルを使用してビルドを実行する

構成ファイルを使用してビルドを手動で実行するには:

プロジェクトのルートディレクトリに、cloudbuild.yaml または cloudbuild.json という名前の Cloud Build ビルド構成ファイルを作成します。
serviceAccount フィールドと、優先するロギング設定を追加します。
- ビルドログを Cloud Logging に保存する場合は、logging フィールドを追加して、そのフィールドの値を CLOUD_LOGGING_ONLY に設定します。
- ユーザーが作成した Cloud Storage バケットにビルドログを保存する場合:
  - logging フィールドを追加して、その値を GCS_ONLY に設定します。
  - logsBucket フィールドを追加し、その値を Cloud Storage バケットのロケーションに設定します。
次のサンプルでは、ユーザー指定のサービスアカウントを使用してビルドを実行するように Cloud Build を構成し、ビルドログをユーザーが作成した Cloud Storage バケットに保存するよう構成しています。
YAML
```
steps:
- name: 'bash'
  args: ['echo', 'Hello world!']
logsBucket: 'LOGS_BUCKET_LOCATION'
serviceAccount: 'projects/PROJECT_ID/serviceAccounts/SERVICE_ACCOUNT'
options:
  logging: GCS_ONLY
```
JSON
```
{
  "steps": [
  {
    "name": "bash",
    "args": [
      "echo",
      "Hello world!"
    ]
  }
  ],
  "logsBucket": "LOGS_BUCKET_LOCATION",
  "serviceAccount": "projects/PROJECT_ID/serviceAccounts/SERVICE_ACCOUNT",
  "options": {
    "logging": "GCS_ONLY"
  }
}
```
ビルド構成ファイルのプレースホルダ値を次のように置き換えます。
- LOGS_BUCKET_LOCATION: ビルドログを保存する Cloud Storage バケット。例: gs://mylogsbucket
- PROJECT_ID は、ビルドを実行する Google Cloud プロジェクトの ID です。
- SERVICE_ACCOUNT は、ビルドに指定するサービスアカウントのメールアドレスまたは一意の ID です。たとえば、サービスアカウントのメールアドレスは次のようになります。service-account-name@project-id.iam.gserviceaccount.com
ビルド構成ファイルを使用してビルドを開始します。
```
gcloud builds submit --config CONFIG_FILE_PATH SOURCE_DIRECTORY
```
上記のコマンドのプレースホルダ値を次のように置き換えます。
- CONFIG_FILE_PATH は、ビルド構成ファイルへのパスです。
- SOURCE_DIRECTORY は、ソースコードのパスまたは URL です。
gcloud builds submit コマンドに CONFIG_FILE_PATH と SOURCE_DIRECTORY を指定しない場合、Cloud Build は、ビルド構成ファイルとソースコードが現在の作業ディレクトリにあると想定します。

トリガーを使用してビルドを実行する

独自のサービスアカウントで Cloud Build トリガーを使用してビルドを実行するには、トリガーの作成時に任意のロギングオプションを設定し、任意のサービスアカウントを選択します。

ビルド構成ファイルで、次のことを行います。
- ビルドログを Cloud Logging に保存する場合は、logging フィールドを追加して、そのフィールドの値を CLOUD_LOGGING_ONLY に設定します。
- ユーザーが作成した Cloud Storage バケットにビルドログを保存する場合:
  - logging フィールドを追加して、その値を GCS_ONLY に設定します。
  - logsBucket フィールドを追加し、その値を Cloud Storage バケットのロケーションに設定します。
次のサンプルでは、ユーザーが作成した Cloud Storage バケットに保存されるようビルドログが構成されています。
YAML
```
steps:
- name: 'bash'
  args: ['echo', 'Hello world!']
logsBucket: 'LOGS_BUCKET_LOCATION'
options:
  logging: GCS_ONLY
```
JSON
```
{
  "steps": [
  {
    "name": "bash",
    "args": [
      "echo",
      "Hello world!"
    ]
  }
  ],
  "logsBucket": "LOGS_BUCKET_LOCATION",
  "options": {
    "logging": "GCS_ONLY"
  }
}
```
LOGS_BUCKET_LOCATION は、ビルドログを保存する Cloud Storage バケットに置き換えます。例: gs://mylogsbucket
使用するサービスアカウントをビルドトリガーで次のように指定します。
コンソール
Google Cloud コンソールの [トリガー] ページを使用してビルドを実行するには、ユーザー指定のサービスアカウントがビルドトリガーと同じプロジェクト内に存在している必要があります。プロジェクト間のサービスアカウントでトリガーを使用するには、gcloud ツールを使用してビルドトリガーを作成します。
1. ビルドトリガーを作成または編集します。
2. [サービスアカウント] フィールドにサービスアカウントを指定します。サービスアカウントを指定しない場合、Cloud Build はデフォルトのサービスアカウントを使用します。
3. [作成] をクリックして、ビルドトリガーを保存します。
gcloud
ビルドトリガーを作成する際に、--service-account フラグを使用してサービスアカウントを指定します。次のサンプルでは、gcloud コマンドによって、Git リポジトリからコードを pull するビルドトリガーが作成されます。
```
gcloud builds triggers create github \
   --name=TRIGGER_NAME \
   --repo-name=REPO_NAME \
   --repo-owner=REPO_OWNER \
   --branch-pattern=BRANCH_PATTERN
   --build-config=BUILD_CONFIG_FILE
   --service-account=SERVICE_ACCOUNT
   --project=BUILD_PROJECT
```
ビルド構成ファイルのプレースホルダ値を次のように置き換えます。
- TRIGGER_NAME はビルドトリガーの名前です。
- REPO_NAME はリポジトリの名前です。
- REPO_OWNER は、リポジトリオーナーのユーザー名です。
- BRANCH_PATTERN は、ビルドを呼び出すリポジトリ内のブランチ名です。
- TAG_PATTERN は、ビルドを呼び出すリポジトリ内のタグ名です。
- BUILD_CONFIG_FILE はビルド構成ファイルのパスです。
- SERVICE_ACCOUNT は、/projects/PROJECT_ID/serviceAccounts/ACCOUNT_ID_OR_EMAIL 形式のサービスアカウントです。
- BUILD_PROJECT は、ビルドを開始するプロジェクトです。

プロジェクト間の設定

ユーザー指定のサービスアカウントが、ビルドを開始するプロジェクトとは異なるプロジェクトにある場合は、必要なアクセス権を付与します。

ユーザー指定のサービスアカウントを含むプロジェクトで、iam.disableCrossProjectServiceAccountUsage 組織のポリシー制約が適用されていないことを確認します。この制約はデフォルトで適用されます。この組織のポリシーの制約を無効にするには、次のコマンドを実行します。ここで、SERVICE_ACCOUNT_PROJECT_ID はユーザー指定のサービスアカウントを含むプロジェクトです。
```
gcloud resource-manager org-policies disable-enforce \
   iam.disableCrossProjectServiceAccountUsage \
   --project=SERVICE_ACCOUNT_PROJECT_ID
```
ユーザー指定のサービスアカウントを含むプロジェクトで、ビルドを実行するプロジェクトの Cloud Build サービスエージェントに roles/iam.serviceAccountTokenCreator ロールを付与します。
```
gcloud projects add-iam-policy-binding SERVICE_ACCOUNT_PROJECT_ID \
    --member="serviceAccount:BUILD_SERVICE_AGENT" \
    --role="roles/iam.serviceAccountTokenCreator"
```
コマンドのプレースホルダ値を、次のように置き換えます。
- SERVICE_ACCOUNT_PROJECT_ID: ユーザー指定のサービスアカウントを含むプロジェクトのプロジェクト ID。
- BUILD_SERVICE_AGENT: service-BUILD_PROJECT_NUMBER@gcp-sa-cloudbuild.iam.gserviceaccount.com 形式のサービスエージェントのメール ID。ここで、BUILD_PROJECT_NUMBER はビルドを実行しているプロジェクトのプロジェクト番号です。プロジェクト番号は、プロジェクト設定のページで確認できます。

制限事項:

Google Cloud プロジェクトは Google Cloud 組織に存在している必要があります。
gcloud builds submit または gcloud builds triggers create を使用して、コマンドラインでビルドを開始する必要があります。Google Cloud コンソールの [トリガー] ページを使用するには、ユーザー指定のサービスアカウントとビルドトリガーが同じプロジェクト内にある必要があります。

次のステップ

Cloud Build IAM のロールと権限の詳細を確認する。
サービスアカウントの変更がビルドの実行方法に影響する仕組みについて学習する。

ユーザー指定のサービス アカウントを構成する