デプロイメントパイプラインとの Workload Identity 連携を構成する

このガイドでは、Workload Identity 連携を使用して、デプロイパイプラインで Google Cloud に対する認証を行えるようにする方法について説明します。

使用している CI / CD システムによっては、デプロイパイプラインからアンビエントな環境固有の認証情報にアクセスできる場合があります。次に例を示します。

GitHub Actions ワークフローでは、GitHub OIDC トークンを取得して、ワークフローとそのリポジトリを一意に識別できます。
GitLab SaaS を使用すると、CI/CD ジョブでジョブとプロジェクト、環境、リポジトリを一意に識別する ID トークンにアクセスできます。
Terraform Cloud では、ワークスペースと環境を一意に識別する OIDC トークンを Terraform 構成に指定できます。

Workload Identity 連携を使用することで、これらの認証情報を使用して Google Cloud に対する認証を行うようにデプロイパイプラインを構成できます。これにより、サービスアカウントキーに関連するメンテナンスとセキュリティの負担がなくなります。

外部 IdP を準備する

GitHub Actions

GitHub アカウントで構成を変更する必要はありません。

GitHub リポジトリを信頼するように Workload Identity プールを構成すると、そのリポジトリのワークフローで GitHub OIDC トークンを使用して、有効期間の短い Google Cloud 認証情報を取得できます。

GitLab SaaS

GitLab アカウントで構成を変更する必要はありません。

GitLab グループを信頼するように Workload Identity プールを構成した後、個々の CI/CD ジョブに対して Workload Identity 連携を有効にできます。

Terraform Cloud

Terraform Cloud アカウントで構成を変更する必要はありません。

Terraform Cloud を信頼するように Workload Identity プールを構成すると、個々のワークスペースで Workload Identity 連携を有効にできます。

Workload Identity 連携を構成する

この手順は、GitHub 組織、GitLab グループ、Terraform Cloud 組織ごとに行う必要があります。

Workload Identity 連携の構成を開始するには、次の操作を行います。

Google Cloud Console の [プロジェクトセレクタ] ページで、Google Cloud プロジェクトを選択または作成します。

プロジェクトセレクタに移動

Workload Identity プールとプロバイダの管理に専用のプロジェクトを使用する

Google Cloud プロジェクトで課金が有効になっていることを確認します。

IAM, Resource Manager, Service Account Credentials, and Security Token Service API を有効にします。

API を有効にする

属性のマッピングと条件を定義する

デプロイパイプラインの環境固有の認証情報には複数の属性が含まれているため、Google Cloud でサブジェクト識別子（google.subject）として使用する属性を決定する必要があります。

必要に応じて、追加の属性をマッピングできます。これにより、リソースへのアクセス権を付与する際にこれらの追加属性を参照できます。

GitHub Actions

属性マッピングでは、GitHub Actions OIDC トークン内のすべてのクレームを使用できます。これらのトークンクレームキーとその値は GitHub によって制御されます。少なくとも、GitHub Actions OIDC トークンのサブジェクトに対応する google.subject を assertion.sub にマッピングする必要があります。

google.subject=assertion.sub

GitHub Actions の OIDC トークンのサブジェクトの値は、ソースイベントによって異なる場合があります。その他のクレーム属性には次のようなものがあります。

repository: オーナーとリポジトリ名が含まれます（例: "google/guava"）。
repository_id: 一意のリポジトリ ID が含まれています（例: "20300177"）。
repository_owner: オーナー（ユーザー名または GitHub 組織の名前）が含まれています（例: "google"）。
repository_owner_id: 一意のオーナー ID が含まれています（例: "1342004"）。

このリストは、可能性のあるクレームの一部です。完全なリストについては、クレームの例に関する GitHub ドキュメントをご覧ください。属性条件として使用するクレーム、または今後 principalSet 条件の一部として使用する予定のクレームを必ずマッピングします。

注意: GitHub Actions OIDC トークンクレームをマッピングする場合に、考慮すべき重要なリスクがあります。

repository や repository_owner などの名前フィールドを使用すると、サイバースクワッティングやタイポスクワッティングなどの攻撃を受けるリスクが高くなります。GitHub リポジトリまたは GitHub 組織を削除すると、誰かが同じ名前で ID を確立できる可能性があります。このような状況を防ぐには、数値の *_id フィールドを使用します。これは、GitHub が一意であり、再利用されないことが保証されているフィールドです。

GitHub Actions OIDC トークンに埋め込まれたクレームの一部は、一意であることが保証されていません。他の GitHub 組織またはリポジトリによって発行されたトークンに同じ値が含まれ、ID を確立できる可能性があります。この状況を防ぐには、常に属性条件を使用して、GitHub 組織から発行されたトークンへのアクセスを制限します。

GitLab SaaS

属性マッピングでは、次のような GitLab ID トークンに埋め込まれたクレームをソース属性として使用できます。

sub: プロジェクト名と Git リファレンス（例: project_path:groupname/projectname:ref_type:branch:ref:main）。
namespace_id: 一意のグループ ID。
project_id: 一意のプロジェクト ID。
user_id: 一意のユーザー ID。
environment: ジョブが適用される環境。
ref_path: Git リファレンス（例: refs/heads/main）。

次の属性マッピングでは、google.subject を GitLab ID トークンの sub クレームに設定します。sub クレームにはリポジトリ名と Git リファレンスの両方が含まれるため、このマッピングによりプロジェクトとブランチによるアクセスを制御できます。

google.subject=assertion.sub

リポジトリとブランチによるアクセスの制御は、特定のブランチ（main など）が他のブランチ（機能ブランチなど）以外のリソースに対する異なるアクセスが必要な場合に役立ちます。

場合によっては、プロジェクトまたはグループでアクセスを区別するだけで十分です。したがって、次のマッピングには、GitLab の project_id と namespace_id を含む 2 つの追加の属性が含まれています。

google.subject=assertion.sub
attribute.project_id=assertion.project_id
attribute.namespace_id=assertion.namespace_id

Terraform Cloud

属性マッピングでは、次のような Terraform Cloud OIDC トークンに埋め込まれたクレームを使用できます。

terraform_organization_id: 組織の一意の ID が含まれます（例: org-xxxxxxxxxxxxxxxx）。
terraform_workspace_id: ワークスペースの一意の ID が含まれます（例: ws-xxxxxxxxxxxxxxxx）。
terraform_workspace_name: ワークスペースの表示名が含まれます。
sub: 組織、ワークスペース、フェーズの表示名が含まれます（例: organization:example-org:workspace:example-workspace:run_phase:apply）。

次の属性マッピングは、google.subject を Terraform Cloud OIDC トークンの terraform_workspace_id クレームに設定します。

google.subject=assertion.terraform_workspace_id

このマッピングにより、ワークスペースごとに Google Cloud リソースへのアクセスを制御できます。

属性条件は、アサーション属性とターゲット属性をチェックする CEL 式です。特定の認証情報の属性条件が true と評価されると、認証情報が受け入れられます。それ以外の場合、認証情報は拒否されます。すべての属性条件フィールドに属性マッピングが必要です。

GitHub Actions

GitHub 組織によって発行されたトークンへのアクセスを制限するには、次の属性条件を使用します。

assertion.repository_owner=='ORGANIZATION'

ORGANIZATION は、GitHub 組織の名前に置き換えます。

必要に応じて属性条件を拡張して、ワークフローまたはブランチのサブセットへのアクセスを制限します。たとえば、次の条件は、Git ブランチ main を使用するワークフローへのアクセスを制限します。

assertion.repository_owner=='ORGANIZATION' && assertion.ref=='refs/heads/main'

GitLab SaaS

次の属性条件を使用して、GitLab グループによって発行されるトークンへのアクセスを制限します。

assertion.namespace_id=='GROUP_ID'

GROUP_ID は、GitLab グループのホームページに表示されるグループ ID に置き換えます。

必要に応じて、属性の条件を拡張して、プロジェクト、ブランチ、または環境のサブセットへのアクセスを制限します。たとえば、次の条件では、環境 production を使用するジョブへのアクセスが制限されます。

assertion.namespace_id=='GROUP_ID' && assertion.environment=='production'

Terraform Cloud

Terraform Cloud 組織によって発行されたトークンへのアクセスを制限するには、次の属性条件を使用します。

assertion.terraform_organization_id=='ORGANIZATION_ID'

ORGANIZATION_ID は、組織の一意の ID に置き換えます（例: org-xxxxxxxxxxxxxxxx）。必要に応じて属性条件を拡張して、ワークフローまたはブランチのサブセットへのアクセスを制限します。たとえば、次の属性条件により、特定のワークスペースへのアクセスが制限されます。

assertion.terraform_organization_id=='ORGANIZATION_ID' && terraform_workspace_id=='WORKSPACE_ID'

Workload Identity のプールとプロバイダを作成する

必要なロール

Workload Identity 連携の構成に必要な権限を取得するには、プロジェクトに対して次の IAM ロールを付与するよう管理者に依頼してください。

Workload Identity プール管理者（roles/iam.workloadIdentityPoolAdmin）
サービスアカウント管理者（roles/iam.serviceAccountAdmin）

ロールの付与の詳細については、アクセスの管理をご覧ください。

必要な権限は、カスタムロールや他の事前定義ロールから取得することもできます。

また、IAM オーナー（roles/owner）の基本ロールには ID 連携を構成する権限も含まれています。本番環境では基本ロールを付与すべきではありません。基本ロールは、開発環境またはテスト環境で付与してください。

これで、Workload Identity プールとプロバイダの作成に必要な情報がすべて収集されました。

コンソール

Google Cloud コンソールで、[新しいワークロードプロバイダとプール] ページに移動します。

[新しいワークロードプロバイダとプール] に移動
[ID プールを作成] に、次のように入力します。
- 名前: プールの名前。この名前はプール ID としても使用されます。プール ID を後で変更することはできません。
- 説明: プールの目的を説明するテキスト。
[続行] をクリックします。
プロバイダを構成します。
GitHub Actions
- プロバイダを選択: OpenID Connect（OIDC）。
- プロバイダ名: プロバイダの名前。この名前はプロバイダ ID としても使用されます。プロバイダ ID は後から変更できません。
- 発行元 URL: https://token.actions.githubusercontent.com/
- オーディエンス: デフォルトのオーディエンス
GitLab SaaS
- プロバイダを選択: OpenID Connect（OIDC）。
- プロバイダ名: プロバイダの名前。この名前はプロバイダ ID としても使用されます。プロバイダ ID は後から変更できません。
- 発行元 URL: https://gitlab.com
- オーディエンス: デフォルトのオーディエンス
Terraform Cloud
- プロバイダを選択: OpenID Connect（OIDC）。
- プロバイダ名: プロバイダの名前。この名前はプロバイダ ID としても使用されます。プロバイダ ID は後から変更できません。
- 発行元 URL: https://app.terraform.io
- オーディエンス: デフォルトのオーディエンス
[続行] をクリックします。
[プロバイダの属性を構成する] で、前に確認した属性マッピングを追加します。
[属性条件] で、前に確認した属性条件を入力します。
[保存] をクリックして、Workload Identity のプールとプロバイダを作成します。

gcloud

新しい Workload Identity プールを作成します。
```
gcloud iam workload-identity-pools create POOL_ID \
    --location="global" \
    --description="DESCRIPTION" \
    --display-name="DISPLAY_NAME"
```
次の値を置き換えます。
- POOL_ID: プールの一意の ID。
- DISPLAY_NAME: プールの名前。
- DESCRIPTION: プールの説明。この説明は、プール ID へのアクセス権を付与するときに表示されます。
Workload Identity プールのプロバイダを追加します。
GitHub Actions
```
gcloud iam workload-identity-pools providers create-oidc PROVIDER_ID \
    --location="global" \
    --workload-identity-pool="POOL_ID" \
    --issuer-uri="https://token.actions.githubusercontent.com/" \
    --attribute-mapping="MAPPINGS" \
    --attribute-condition="CONDITIONS"
```
次の値を置き換えます。
- PROVIDER_ID: プロバイダの一意の ID。
- POOL_ID: プールの ID
- MAPPINGS: 前に確認した属性マッピングのカンマ区切りリスト。
- CONDITIONS: 前に確認した属性条件。
GitLab SaaS
```
gcloud iam workload-identity-pools providers create-oidc PROVIDER_ID \
    --location="global" \
    --workload-identity-pool="POOL_ID" \
    --issuer-uri="https://gitlab.com" \
    --attribute-mapping="MAPPINGS" \
    --attribute-condition="CONDITIONS"
```
次の値を置き換えます。
- PROVIDER_ID: プロバイダの一意の ID。
- POOL_ID: プールの ID。
- MAPPINGS: 前に確認した属性マッピングのカンマ区切りリスト。
- CONDITIONS: 前に確認した属性条件。属性条件がない場合は、パラメータを削除します。
Terraform Cloud
```
gcloud iam workload-identity-pools providers create-oidc PROVIDER_ID \
    --location="global" \
    --workload-identity-pool="POOL_ID" \
    --issuer-uri="https://app.terraform.io" \
    --attribute-mapping="MAPPINGS" \
    --attribute-condition="CONDITIONS"
```
次の値を置き換えます。
- PROVIDER_ID: プロバイダの一意の ID。
- POOL_ID: プールの ID。
- MAPPINGS: 前に確認した属性マッピングのカンマ区切りリスト。
- CONDITIONS: 前に確認した属性条件。属性条件がない場合は、パラメータを削除します。

デプロイパイプラインを認証する

この手順は、GitHub Actions ワークフローまたは Terraform Cloud ワークスペースごとに行う必要があります。

デプロイパイプライン用のサービスアカウントを作成する

IAM, Security Token Service, and Service Account Credentials API を有効にします。
API を有効にする
ワークロードを表すサービスアカウントを作成します。デプロイパイプラインごとに専用のサービスアカウントを使用することをおすすめします。

サービスアカウントは、Workload Identity プールと同じプロジェクトにある必要はありません。
外部 ID にアクセスを許可するリソースに対するアクセス権をサービスアカウントに付与します。

デプロイパイプラインによるサービスアカウントの権限借用を許可する

外部 ID にサービスアカウントの権限借用を許可するには、サービスアカウントに Workload Identity ユーザーロール（roles/iam.workloadIdentityUser）を付与します。このロールは、特定の外部 ID または複数の外部 ID に付与できます。

特定の外部 ID の場合は、google.subject 属性をチェックする属性条件を記述します。
外部 ID のグループの場合は、google.groups 属性またはカスタム属性 attribute.NAME をチェックする属性条件を記述します。

コンソール

Google Cloud コンソールを使用して外部 ID にサービスアカウントの権限借用を許可するには、次の操作を行います。

Google Cloud コンソールで、[Workload Identity プール] ページに移動します。

[Workload Identity プール] に移動
更新する Workload Identity プールを見つけて選択します。
選択した Workload Identity プールへのアクセス権を付与するには、[ アクセスを許可] をクリックします。
[サービスアカウント] リストで、権限を借用する外部 ID のサービスアカウントを選択します。
サービスアカウントの権限を借用するプール内の ID を選択するには、次のいずれかを行います。
- Workload Identity プールの特定の ID のみにサービスアカウントの権限借用を許可するには、[フィルタに一致する ID のみ] を選択します。
  
  [属性名] リストで、フィルタする属性を選択します。
  
  [属性値] フィールドに、属性の想定値を入力します。たとえば、属性マッピング google.subject=assertion.sub を使用する場合は、属性名を subject に設定します。属性値には、外部 ID プロバイダによって発行されたトークンの sub クレームの値を設定します。
構成を保存するには、[保存]、[閉じる] の順にクリックします。

gcloud

gcloud CLI を使用して、外部 ID にサービスアカウントの権限借用を許可するには、次の操作を行います。

現在のプロジェクトのプロジェクト番号を取得するには、次のコマンドを実行します。
```
gcloud projects describe $(gcloud config get-value core/project) --format=value$projectNumber$
```

特定の条件を満たす外部 ID に Workload Identity ユーザーロール（roles/iam.workloadIdentityUser）を付与するには:

件名を指定

gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT_EMAIL \
    --role=roles/iam.workloadIdentityUser \
    --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/SUBJECT"

グループを指定

gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT_EMAIL \
    --role=roles/iam.workloadIdentityUser \
    --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/group/GROUP"

属性を指定

gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT_EMAIL \
    --role=roles/iam.workloadIdentityUser \
    --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE"

以下を置き換えます。

SERVICE_ACCOUNT_EMAIL: サービスアカウントのメールアドレス
PROJECT_NUMBER: Workload Identity プールを含むプロジェクトのプロジェクト番号
POOL_ID: Workload Identity プールのプール ID
SUBJECT: google.subject にマッピングされている属性の想定値
GROUP: google.groups にマッピングされている属性の想定値
ATTRIBUTE_NAME: 属性マッピングのカスタム属性の名前

デプロイパイプラインを構成する

この時点で、デプロイパイプラインで Workload Identity 連携を使用する準備ができています。

GitHub Actions

google-github-actions/auth アクションを使用すると、ワークフローの実行中に認証情報構成ファイルを自動的に生成できます。terraform などのクライアントライブラリとツールでは、この認証情報構成ファイルを使用して Google 認証情報を自動的に取得できます。

GitHub Actions YAML ファイルを編集して、次の内容を追加します。

ジョブが GitHub ID トークンを取得できるようにするには、次の構成を追加します。
```
permissions:
  id-token: write
  contents: read
```

認証情報構成ファイルを作成するステップを追加します。

- id: 'auth'
  name: 'Authenticate to Google Cloud'
  uses: 'google-github-actions/auth@v1'
  with:
    create_credentials_file: true
    workload_identity_provider: 'projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID'
    service_account: 'SERVICE_ACCOUNT_EMAIL'

次の値を置き換えます。

PROJECT_NUMBER: Workload Identity プールを含むプロジェクトのプロジェクト番号
POOL_ID: Workload Identity プールの ID
PROVIDER_ID: Workload Identity プールプロバイダの ID
SERVICE_ACCOUNT_EMAIL: サービスアカウントのメールアドレス

例:

jobs:
  build:
    # Allow the job to fetch a GitHub ID token
    permissions:
      id-token: write
      contents: read

    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3

      - id: 'auth'
        name: 'Authenticate to Google Cloud'
        uses: 'google-github-actions/auth@v1'
        with:
          create_credentials_file: true
          workload_identity_provider: 'projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID'
          service_account: 'SERVICE_ACCOUNT_EMAIL'

google-github-actions/auth アクションの使用方法については、Workload Identity 連携の設定をご覧ください。

GitLab SaaS

.gitlab-ci.yml ファイルを編集し、ジョブ構成に以下を追加します。

job:
  variables:
    WORKLOAD_IDENTITY_PROJECT_NUMBER: PROJECT_NUMBER
    WORKLOAD_IDENTITY_POOL: POOL_ID
    WORKLOAD_IDENTITY_PROVIDER: PROVIDER_ID
    SERVICE_ACCOUNT: SERVICE_ACCOUNT_EMAIL
    GOOGLE_APPLICATION_CREDENTIALS: $CI_BUILDS_DIR/.workload_identity.wlconfig

  id_tokens:
    WORKLOAD_IDENTITY_TOKEN:
      aud: https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID

  script:
    - |-
      echo $WORKLOAD_IDENTITY_TOKEN > $CI_BUILDS_DIR/.workload_identity.jwt
      cat << EOF > $GOOGLE_APPLICATION_CREDENTIALS
      {
        "type": "external_account",
        "audience": "//iam.googleapis.com/projects/$WORKLOAD_IDENTITY_PROJECT_NUMBER/locations/global/workloadIdentityPools/$WORKLOAD_IDENTITY_POOL/providers/$WORKLOAD_IDENTITY_PROVIDER",
        "subject_token_type": "urn:ietf:params:oauth:token-type:jwt",
        "token_url": "https://sts.googleapis.com/v1/token",
        "credential_source": {
          "file": "$CI_BUILDS_DIR/.workload_identity.jwt"
        },
        "service_account_impersonation_url": "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/$SERVICE_ACCOUNT:generateAccessToken"
      }
      EOF

次の値を置き換えます。

PROJECT_NUMBER: Workload Identity プールを含むプロジェクトのプロジェクト番号
POOL_ID: Workload Identity プールの ID
PROVIDER_ID: Workload Identity プールプロバイダの ID
SERVICE_ACCOUNT_EMAIL: サービスアカウントのメールアドレス。

この構成では、次の処理が行われます。

GitLab で ID トークンを発行し、そのトークンを WORKLOAD_IDENTITY_TOKEN という名前の環境変数で利用できるように指示します。ID トークンは、Workload Identity プールのプロバイダをオーディエンスとして使用します。
ID トークンを .workload_identity.jwt という名前の一時ファイルに保存します。
認証情報構成ファイルを作成して、クライアントライブラリに .workload_identity.jwt から ID トークンを読み取り、サービスアカウントになりすますように指示します。
認証情報の構成ファイルを指すように環境変数 GOOGLE_APPLICATION_CREDENTIALS を設定します。

Terraform Cloud

Terraform Cloud ワークスペースで Workload Identity 連携を使用して Google Cloud への認証を行えるように構成します。

Terraform Cloud でワークスペースを開き、[Variables] に移動します。

次の変数を追加します。

変数のカテゴリ	キー	値
環境変数	`TFC_GCP_PROVIDER_AUTH`	`true`
環境変数	`TFC_GCP_RUN_SERVICE_ACCOUNT_EMAIL`	サービスアカウントのメールアドレス（例: `terraform@my-project-123.iam.gserviceaccount.com`）
環境変数	`TFC_GCP_PROJECT_NUMBER`	Workload Identity プールを含むプロジェクトのプロジェクト番号
環境変数	`TFC_GCP_WORKLOAD_POOL_ID`	Workload Identity プールの ID
環境変数	`TFC_GCP_WORKLOAD_PROVIDER_ID`	Workload Identity プールプロバイダの ID

必要に応じて環境変数を追加し、Terrform Cloud で plan フェーズと apply フェーズに異なるサービスアカウントを使用できるようにします。詳細については、オプションの環境変数をご覧ください。

変数のリストで、前の手順で追加した 5 つの変数のカテゴリが env に設定されていることを確認します。
Terraform 構成で、バージョン 4.48.0 以降の Google Cloud プロバイダが使用されていることを確認し、必要に応じて次のように更新します。
```
terraform {
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 4.48.0"
    }
  }
}
```
ソースコードリポジトリに変更を送信します。

次のステップ

Workload Identity 連携について確認する。
デプロイパイプラインでの Workload Identity 連携の使用に関するベストプラクティスを確認する。
Workload Identity プールとプロバイダの管理方法を学習する。

デプロイメント パイプラインとの Workload Identity 連携を構成する

外部 IdP を準備する

GitHub Actions

GitLab SaaS

Terraform Cloud

Workload Identity 連携を構成する

属性のマッピングと条件を定義する

GitHub Actions

GitLab SaaS

Terraform Cloud

GitHub Actions

GitLab SaaS

Terraform Cloud

Workload Identity のプールとプロバイダを作成する

必要なロール

コンソール

GitHub Actions

GitLab SaaS

Terraform Cloud

gcloud

GitHub Actions

GitLab SaaS

Terraform Cloud

デプロイ パイプラインを認証する

デプロイ パイプライン用のサービス アカウントを作成する

デプロイ パイプラインによるサービス アカウントの権限借用を許可する

コンソール

gcloud

件名を指定

グループを指定

属性を指定

デプロイ パイプラインを構成する

GitHub Actions

GitLab SaaS

Terraform Cloud

次のステップ

デプロイメントパイプラインとの Workload Identity 連携を構成する

デプロイパイプラインを認証する

デプロイパイプライン用のサービスアカウントを作成する

デプロイパイプラインによるサービスアカウントの権限借用を許可する

デプロイパイプラインを構成する