サービス アカウントを指定しない場合、Cloud Build がユーザーの代わりにビルドを実行するサービス アカウントを自動的に選択する場合があります。このサービス アカウントには、プロジェクト内の Cloud Source Repositories や Cloud Storage バケットへのアクセスなど、ユースケースに対して必要以上に幅広い権限が付与されている場合があります。
プロジェクトのセキュリティ体制を強化し、構成ミスや悪意のあるユーザーの潜在的な影響を減らすには、最小権限の原則に従うことをおすすめします。この原則を採用することで、実行するタスクに限られた範囲の権限とロールを各サービス アカウントに割り当てることができます。たとえば、Google Cloud ブログで説明されるように、1 つのサービス アカウントでイメージのビルドと Artifact Registry への push が可能です。
始める前に
-
Enable the Cloud Build and IAM APIs.
有効期間が短い認証情報を作成するなど、このアカウントを使用して認証情報の作成と管理を行う場合は、IAM Service Account Credentials API を有効にします。
まだ作成していない場合は、サービス アカウントを作成します。
IAM 権限を付与
ビルドが接続先のサービスにアクセスできるようにするには、いくつかのロールと権限を付与する必要があります。
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
ツールを使用してビルドトリガーを作成します。[サービス アカウント] フィールドにサービス アカウントを指定します。サービス アカウントを指定しない場合、Cloud Build はデフォルトのサービス アカウントを使用します。
[作成] をクリックして、ビルドトリガーを保存します。
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
は、サービス アカウントに関連付けられたメールです。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 のロールと権限の詳細を確認する。
- サービス アカウントの変更がビルドの実行方法に影響する仕組みについて学習する。