このページでは、サービス アカウント ID を使用するための有効期間が短いサービス アカウント認証情報を作成する方法を説明します。
サービス アカウントは、有効期間が短い認証情報を使用して、Google Cloud APIs やその他の Google 以外の API への呼び出しを認証できます。有効期間が短い認証情報の存続期間は限られており、その期間は数時間未満です。有効期間が短いサービス アカウント認証情報は、信頼できるサービス アカウントのリソースへのアクセスを制限する必要がある場合に便利です。また、サービス アカウントキーなどの長期間有効な認証情報よりもリスクが低くなります。
サポートされている認証情報タイプには、OAuth 2.0 アクセス トークン、OpenID Connect ID トークン、自己署名 JSON ウェブトークン(JWT)、自己署名バイナリ オブジェクト(BLOB)などがあります。OAuth 2.0 アクセス トークンと OpenID Connect(OIDC)ID トークンが、特によく使用されるタイプの認証情報です。いくつかのサンプル事例としては、次のようなものがあります。
OAuth 2.0 アクセス トークン: OAuth 2.0 アクセス トークンは、サービス アカウントから Google Cloud APIs へのアクセスを認証するのに便利です。たとえば、サービス アカウントに属する OAuth 2.0 アクセス トークンを作成しておくことで、サービス管理者はそのサービス アカウントを使用して Google Cloud APIs を呼び出し、プロジェクトで昇格した権限を取得することが可能になります。トークンの有効期間は短いため、昇格した権限は一時的なものです。有効期間の短いトークンを使用することにより、ID とリソース間で最小権限の原則を実装しやすくなります。また、本番環境で緊急事態が発生し、サービス管理者がデバッグのために有効期間が短い昇格した承認を必要とする場合に便利です。
OIDC ID トークン: An OIDC ID トークンは、OpenID Connect を認可するサービスに対するサービス アカウント ID の認証に便利です。たとえば、サービス アカウントに属する OIDC ID トークンを作成しておくことで、Google Cloud で実行されるサービスが、サードパーティ プロバイダにデプロイされているその他のサービス(データ パイプライン ジョブなど)で自身の認証を行うことができるようになります。ターゲット サービスが OIDC で構成されている場合、認証は成功します。
始める前に
- IAM サービス アカウントを理解する
- まだ有効にしていない場合は、クイックスタートの手順に沿って請求と IAM API を有効にします。
サービス アカウントの作成
開始するには、新しいサービス アカウントを作成します。
必要な権限の付与
呼び出し元がサービス アカウントの有効期間が短い認証情報を作成するには、2 つの異なるフローがあります。各フローには適切な権限が必要です。
- 直接リクエスト: 呼び出し元は Google アカウントまたはサービス アカウントのいずれかとして認証され、有効期間が短い認証情報の作成を直接リクエストします。このフローには、呼び出し元と認証情報が作成されるサービス アカウントの 2 つの ID が含まれます。
委任リクエスト: 呼び出し元は直接リクエスト フローの場合と同じように Google アカウントまたはサービス アカウントのいずれかとして認証されますが、リクエストは委任チェーン内の 1 つ以上のサービス アカウントに委任されます。このフローでは、複数のサービス アカウントが、元の呼び出し元と認証情報が作成されるサービス アカウントの間の仲介役として機能します。委任チェーン内の各サービス アカウントには、リクエストを渡すための権限が必要です。
このフローが利用できるのは、プロジェクト内に権限が制限された複数のサービス アカウントが何層にも重なっていて、各サービス アカウントが、特定のリソースに対して特定の機能や限定された機能を行うように構成されている場合です。たとえば、あるサービス アカウントには Cloud Storage のリソースに対する権限のみが付与され、別のサービス アカウントには Compute Engine のリソースに対する権限のみが付与されている、といった状況です。サービス アカウント同士でリクエストの委任が正しく行われるようにするには、各サービス アカウントが委任チェーンの一覧に含まれていなければなりません。
直接リクエストの権限
このページの必要な権限の付与で説明されているように、直接リクエストには呼び出し元と認証情報が作成されるサービス アカウントのみが含まれます。このフローに次の ID があるとします。
- サービス アカウント 1(
sa-1
): 有効期間が短い認証情報のリクエストを発行する呼び出し元。 - サービス アカウント 2(
sa-2
): 認証情報が作成される権限を制限したアカウント。
有効期間が短い認証情報を作成する権限を sa-1
に付与するには、sa-2
でサービス アカウント トークン作成者のロール(roles/iam.serviceAccountTokenCreator
)を付与します。これは、サービス アカウントが ID ではなくリソースのように扱われる例です。sa-1
には、sa-2
の認証情報を発行する権限を付与する必要があります。ID またはリソースとしてサービス アカウントを扱う方法について詳しくは、サービス アカウント権限をご覧ください。
次の手順では REST API で必要な権限を付与しますが、Cloud Console や gcloud
コマンドライン ツールを使用することもできます。
API
最初に sa-2
の IAM ポリシーを読み取ります。
serviceAccounts.getIamPolicy
メソッドで、サービス アカウントの IAM ポリシーを取得します。
後述のリクエストのデータを使用する前に、次のように置き換えます。
project-id
: Google Cloud プロジェクト ID。sa-2
: サービス アカウント 2 の名前。policy-version
: 返されるポリシー バージョン。リクエストでは、最新のポリシー バージョン(ポリシー バージョン 3)を指定する必要があります。詳細については、ポリシーの取得時にポリシー バージョンを指定するをご覧ください。
HTTP メソッドと URL:
POST https://iam.googleapis.com/v1/projects/project-id/serviceAccounts/sa-2@project-id.iam.gserviceaccount.com:getIamPolicy
JSON 本文のリクエスト:
{ "options": { "requestedPolicyVersion": policy-version } }
リクエストを送信するには、次のいずれかのオプションを展開します。
次のような JSON レスポンスが返されます。
{ "version": 1, "etag": "BwWKmjvelug=", "bindings": [ { "role": "roles/serviceAccountAdmin", "members": [ "user:admin@example.com" ] } ] }
サービス アカウントにロールを割り当てていない場合、レスポンスには etag
値のみが含まれます。この etag
値を次のステップに含めます。
次に、ポリシーを変更して sa-1
にサービス アカウント トークン作成者のロール(roles/iam.serviceAccountTokenCreator
)を付与します。
たとえば、前の手順のサンプル レスポンスを変更するには、次のコードを追加します。
{ "version": 1, "etag": "BwWKmjvelug=", "bindings": [ { "role": "roles/serviceAccountAdmin", "members": [ "user:admin@example.com" ] }, { "role": "roles/iam.serviceAccountTokenCreator", "members": [ "serviceAccount:sa-1@project-id.iam.gserviceaccount.com" ] } ] }
最後に、更新されたポリシーを記述します。
serviceAccounts.setIamPolicy
メソッドによって、サービス アカウントの更新済み IAM ポリシーが設定されます。
後述のリクエストのデータを使用する前に、次のように置き換えます。
project-id
: Google Cloud プロジェクト ID。sa-2
: サービス アカウント 2 の名前。-
policy
: 設定するポリシーの JSON 表現。ポリシーの形式については、ポリシー リファレンスをご覧ください。たとえば、前の手順で示したポリシーを設定するには、
policy
を次のコードに置き換えます。{ "version": 1, "etag": "BwWKmjvelug=", "bindings": [ { "role": "roles/serviceAccountAdmin", "members": [ "user:admin@example.com" ] }, { "role": "roles/iam.serviceAccountTokenCreator", "members": [ "serviceAccount:sa-1@project-id.iam.gserviceaccount.com" ] } ] }
HTTP メソッドと URL:
POST https://iam.googleapis.com/v1/projects/project-id/serviceAccounts/sa-2@project-id.iam.gserviceaccount.com:setIamPolicy
JSON 本文のリクエスト:
{ "policy": policy }
リクエストを送信するには、次のいずれかのオプションを展開します。
レスポンスには、更新されたポリシーが含まれます。
委任リクエストの権限
このページの必要な権限の付与で説明したように、委任されたリクエストには、呼び出し元、委任チェーン内の 1 つ以上のサービス アカウント、最後にサービス アカウントという 3 つ以上の ID が含まれます。このフローに次の ID があるとします。
- サービス アカウント 1(
sa-1
): 有効期間が短い認証情報のリクエストを発行する呼び出し元。 - サービス アカウント 2(
sa-2
): 最初のリクエストをsa-3
に委任する中間サービス アカウント。 - サービス アカウント 3(
sa-3
): 認証情報が作成される権限が制限されたアカウント。
委任を許可するには、各アカウントでチェーン内の前のアカウントにサービス アカウント トークン作成者のロール(roles/iam.serviceAccountTokenCreator
)を付与する必要があります。
この例では、sa-1
に sa-2
のサービス アカウント トークン作成者のロール(roles/iam.serviceAccountTokenCreator
)を付与する必要があります。これは、サービス アカウントが ID ではなくリソースのように扱われる例です。sa-1
には sa-2
のアクセスを委任する権限を付与する必要があります。ID またはリソースとしてサービス アカウントを扱う方法について詳しくは、サービス アカウント権限をご覧ください。
このフローの例では、仲介サービス アカウントは 1 つだけです。複数のサービス アカウントを介してアクセスを委任するには、チェーン内のその他のサービス アカウントにもこのロールを割り当てる必要があります。
次に、sa-2
には sa-3
のサービス アカウント トークン作成者のロール(roles/iam.serviceAccountTokenCreator
)も付与する必要があります。これにより、sa-2
は sa-3
の有効期間が短い認証情報を作成できます。
次の手順では REST API で必要な権限を付与しますが、Cloud Console や gcloud
コマンドライン ツールを使用することもできます。
API
まず、sa-2
(仲介サービス アカウント)の IAM ポリシーを取得します。
serviceAccounts.getIamPolicy
メソッドで、サービス アカウントの IAM ポリシーを取得します。
後述のリクエストのデータを使用する前に、次のように置き換えます。
project-id
: Google Cloud プロジェクト ID。sa-2
: サービス アカウント 2 の名前。policy-version
: 返されるポリシー バージョン。リクエストでは、最新のポリシー バージョン(ポリシー バージョン 3)を指定する必要があります。詳細については、ポリシーの取得時にポリシー バージョンを指定するをご覧ください。
HTTP メソッドと URL:
POST https://iam.googleapis.com/v1/projects/project-id/serviceAccounts/sa-2@project-id.iam.gserviceaccount.com:getIamPolicy
JSON 本文のリクエスト:
{ "options": { "requestedPolicyVersion": policy-version } }
リクエストを送信するには、次のいずれかのオプションを展開します。
次のような JSON レスポンスが返されます。
{ "version": 1, "etag": "BwWKmjvelug=", "bindings": [ { "role": "roles/serviceAccountAdmin", "members": [ "user:admin@example.com" ] } ] }
サービス アカウントにロールを付与していない場合、レスポンスには etag
値のみが含まれます。この etag
値を次のステップに含めます。
次に、ポリシーを変更して sa-1
にサービス アカウント トークン作成者のロール(roles/iam.serviceAccountTokenCreator
)を付与します。
たとえば、前の手順のサンプル レスポンスを変更するには、次のコードを追加します。
{ "version": 1, "etag": "BwWKmjvelug=", "bindings": [ { "role": "roles/serviceAccountAdmin", "members": [ "user:admin@example.com" ] }, { "role": "roles/iam.serviceAccountTokenCreator", "members": [ "serviceAccount:sa-1@project-id.iam.gserviceaccount.com" ] } ] }
次に、sa-2
に対する更新されたポリシーを記述します。
serviceAccounts.setIamPolicy
メソッドによって、サービス アカウントの更新済み IAM ポリシーが設定されます。
後述のリクエストのデータを使用する前に、次のように置き換えます。
project-id
: Google Cloud プロジェクト ID。sa-2
: サービス アカウント 2 の名前。-
policy
: 設定するポリシーの JSON 表現。ポリシーの形式については、ポリシー リファレンスをご覧ください。たとえば、前の手順で示したポリシーを設定するには、
policy
を次のコードに置き換えます。{ "version": 1, "etag": "BwWKmjvelug=", "bindings": [ { "role": "roles/serviceAccountAdmin", "members": [ "user:admin@example.com" ] }, { "role": "roles/iam.serviceAccountTokenCreator", "members": [ "serviceAccount:sa-1@project-id.iam.gserviceaccount.com" ] } ] }
HTTP メソッドと URL:
POST https://iam.googleapis.com/v1/projects/project-id/serviceAccounts/sa-2@project-id.iam.gserviceaccount.com:setIamPolicy
JSON 本文のリクエスト:
{ "policy": policy }
リクエストを送信するには、次のいずれかのオプションを展開します。
レスポンスには、更新されたポリシーが含まれます。
次に、sa-3
(認証情報が作成されるサービス アカウント)の IAM ポリシーを取得します。
serviceAccounts.getIamPolicy
メソッドで、サービス アカウントの IAM ポリシーを取得します。
後述のリクエストのデータを使用する前に、次のように置き換えます。
project-id
: Google Cloud プロジェクト ID。sa-3
: サービス アカウント 3 の名前。policy-version
: 返されるポリシー バージョン。リクエストでは、最新のポリシー バージョン(ポリシー バージョン 3)を指定する必要があります。詳細については、ポリシーの取得時にポリシー バージョンを指定するをご覧ください。
HTTP メソッドと URL:
POST https://iam.googleapis.com/v1/projects/project-id/serviceAccounts/sa-3@project-id.iam.gserviceaccount.com:getIamPolicy
JSON 本文のリクエスト:
{ "options": { "requestedPolicyVersion": policy-version } }
リクエストを送信するには、次のいずれかのオプションを展開します。
次のような JSON レスポンスが返されます。
{ "version": 1, "etag": "BwWKmjvelug=", "bindings": [ { "role": "roles/serviceAccountAdmin", "members": [ "user:admin@example.com" ] } ] }
サービス アカウントにロールを割り当てていない場合、レスポンスには etag
値のみが含まれます。この etag
値を次のステップに含めます。
次に、ポリシーを変更して sa-2
にサービス アカウント トークン作成者のロール(roles/iam.serviceAccountTokenCreator
)を付与します。
たとえば、前の手順のサンプル レスポンスを変更するには、次のコードを追加します。
{ "version": 1, "etag": "BwWKmjvelug=", "bindings": [ { "role": "roles/serviceAccountAdmin", "members": [ "user:admin@example.com" ] }, { "role": "roles/iam.serviceAccountTokenCreator", "members": [ "serviceAccount:sa-2@project-id.iam.gserviceaccount.com" ] } ] }
最後に、更新されたポリシーを記述します。
serviceAccounts.setIamPolicy
メソッドによって、サービス アカウントの更新済み IAM ポリシーが設定されます。
後述のリクエストのデータを使用する前に、次のように置き換えます。
project-id
: Google Cloud プロジェクト ID。sa-3
: サービス アカウント 3 の名前。-
policy
: 設定するポリシーの JSON 表現。ポリシーの形式については、ポリシー リファレンスをご覧ください。たとえば、前の手順で示したポリシーを設定するには、
policy
を次のコードに置き換えます。{ "version": 1, "etag": "BwWKmjvelug=", "bindings": [ { "role": "roles/serviceAccountAdmin", "members": [ "user:admin@example.com" ] }, { "role": "roles/iam.serviceAccountTokenCreator", "members": [ "serviceAccount:sa-2@project-id.iam.gserviceaccount.com" ] } ] }
HTTP メソッドと URL:
POST https://iam.googleapis.com/v1/projects/project-id/serviceAccounts/sa-3@project-id.iam.gserviceaccount.com:setIamPolicy
JSON 本文のリクエスト:
{ "policy": policy }
リクエストを送信するには、次のいずれかのオプションを展開します。
レスポンスには、更新されたポリシーが含まれます。
有効期間が短い認証情報のリクエスト
各 ID に対して適切な権限を付与した後、目的のサービス アカウントに属する有効期間が短い認証情報をリクエストできます。サポートされている認証情報タイプは、次のとおりです。
これらのリクエストの委任チェーンを指定する方法については、このページの委任チェーンの指定をご覧ください。
OAuth 2.0 アクセス トークンの生成
デフォルトでは、OAuth 2.0 アクセス トークンは最大 1 時間(3,600 秒)有効です。ただし、これらのトークンの最大有効期間は 12 時間(43,200 秒)まで延長できます。これを行うには、トークンの有効時間を延長する必要があるサービス アカウントを指定して、constraints/iam.allowServiceAccountCredentialLifetimeExtension
リスト型制約が含まれる組織のポリシーに、指定したサービス アカウントを追加します。そうすると、それらのサービス アカウント用にトークンを作成するときに最大 43,200 秒の有効期間を指定できます。
サービス アカウントの OAuth 2.0 アクセス トークンを生成するには、次の手順に従います。
API
Service Account Credentials API の serviceAccounts.generateAccessToken
メソッドによって、サービス アカウントの OAuth 2.0 アクセス トークンが生成されます。
後述のリクエストのデータを使用する前に、次のように置き換えます。
sa-name
: トークンを作成するサービス アカウントの名前。project-id
: Google Cloud プロジェクト ID。delegates
: 委任されたリクエスト フローを使用している場合は、このページの委任チェーンの指定をご覧ください。委任がない直接リクエスト フローを使用している場合は、リクエスト本文のdelegates
フィールドを省略します。scopes
: リクエストの OAuth 2.0 スコープ。次のスコープは、generateAccessToken
API を呼び出す場合に有効です。"https://www.googleapis.com/auth/iam"
"https://www.googleapis.com/auth/cloud-platform"
-
lifetime
: アクセス トークンが期限切れになるまでの秒数。例:300s
デフォルトでは、トークンの最大有効期間は 1 時間(3,600 秒)です。これらのトークンの最大有効期間を 12 時間(43,200 秒)まで延長するには、
constraints/iam.allowServiceAccountCredentialLifetimeExtension
リスト型制約が含まれる組織のポリシーにサービス アカウントを追加します。
HTTP メソッドと URL:
POST https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/sa-name@project-id.iam.gserviceaccount.com:generateAccessToken
JSON 本文のリクエスト:
{ "delegates": [ delegates ], "scope": [ scopes ], "lifetime": "lifetime" }
リクエストを送信するには、次のいずれかのオプションを展開します。
generateAccessToken
リクエストが成功した場合、レスポンスの本文には OAuth 2.0 アクセス トークンと有効期限が含まれます。expireTime
に達するまで、サービス アカウントの代わりに accessToken
をリクエストの認証に使用できます。
{ "accessToken": "eyJ0eXAi...NiJ9", "expireTime": "2020-04-07T15:01:23.045123456Z" }
OpenID Connect ID トークンの生成
OpenID Conect ID トークンは、1 時間(3,600 秒間)有効です。サービス アカウントの ID トークンを生成するには、次の手順に従います。
API
Service Account Credentials API の serviceAccounts.generateIdToken
メソッドによって、サービス アカウントの OpenID Connect ID トークンが生成されます。
後述のリクエストのデータを使用する前に、次のように置き換えます。
sa-name
: トークンを作成するサービス アカウントの名前。project-id
: Google Cloud プロジェクト ID。delegates
: 委任されたリクエスト フローを使用している場合は、このページの委任チェーンの指定をご覧ください。委任がない直接リクエスト フローを使用している場合は、リクエスト本文のdelegates
フィールドを省略します。
HTTP メソッドと URL:
POST https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/sa-name@project-id.iam.gserviceaccount.com:generateIdToken
JSON 本文のリクエスト:
{ "delegates": [ delegates ], "audience": "sa-name@project-id.iam.gserviceaccount.com", "includeEmail": "true" }
リクエストを送信するには、次のいずれかのオプションを展開します。
generateId
リクエストが成功した場合、レスポンス本文には 1 時間有効な ID トークンが含まれます。サービス アカウントの代わりに token
をリクエストの認証に使用できます。
{ "token": "eyJ0eXAi...NiJ9" }
自己署名 JSON ウェブトークン(JWT)の作成
自己署名 JSON ウェブトークン(JWT)は、次のようなさまざまなシナリオにおいて有用です。
- Google の認証ガイドに従って Google API の呼び出しを認証する。
- App Engine アプリケーションなど、Google Cloud または Google 以外のサービス間で安全に通信する。このシナリオでは、1 つのアプリケーションが、認証目的で別のアプリケーションによって確認できるトークンに署名できます。
- ユーザー、アカウント、デバイスに関する任意のクレームを含む JWT に署名することにより、サービス アカウントを ID プロバイダとして扱う。
サービス アカウントの自己署名 JWT を生成するには、次の手順に従います。
API
Service Account Credentials API の serviceAccounts.signJwt
メソッドでは、サービス アカウントのシステムで管理する秘密鍵を使用して JWT に署名します。
後述のリクエストのデータを使用する前に、次のように置き換えます。
sa-name
: トークンを作成するサービス アカウントの名前。project-id
: Google Cloud プロジェクト ID。delegates
: 委任されたリクエスト フローを使用している場合は、このページの委任チェーンの指定をご覧ください。委任がない直接リクエスト フローを使用している場合は、リクエスト本文のdelegates
フィールドを省略します。-
jwt-payload
: 署名する JWT ペイロード。これは JWT クレームセットを含む JSON オブジェクトです。ご希望のユースケースに必要なクレームを含め、呼び出すサービスの検証要件を満たしてください。Google API を呼び出す場合は、クレーム要件について Google の認証ガイドをご覧ください。exp
(有効期限)クレームは、今後 12 時間以内にする必要があります。Google API を呼び出す場合は、exp
クレームは 1 時間以内に設定する必要があります。次の例のペイロードには、Google API を呼び出すクレームが含まれています。ここで、
exp
は有効期限を表す整数タイムスタンプです。{ \"iss\": \"sa-name@project-id.iam.gserviceaccount.com\", \"sub\": \"sa-name@project-id.iam.gserviceaccount.com\", \"aud\": \"https://firestore.googleapis.com/\", \"iat\": 1529350000, \"exp\": exp }
HTTP メソッドと URL:
POST https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/sa-name@project-id.iam.gserviceaccount.com:signJwt
JSON 本文のリクエスト:
{ "delegates": [ delegates ], "payload": "jwt-payload" }
リクエストを送信するには、次のいずれかのオプションを展開します。
If the
signedJwt
値を署名なしトークンとして使用してリクエストを直接認証できます。トークンは、リクエストで指定された有効期限まで有効です。
{ "keyId": "42ba1e...fc0a", "signedJwt": "eyJ0eXAi...NiJ9" }
自己署名 blob の作成
自己署名 blob は、通常は認証目的で任意のバイナリデータを安全に送信する必要がある場合に便利です。たとえば、カスタム プロトコル / トークンタイプ(JWT ではなく)を使用する場合は、ダウンストリーム サービスで使用するためにそのデータを署名付き blob に含めることができます。
サービス アカウントの自己署名 blob を生成するには、次の手順に沿って操作します。
API
Service Account Credentials API の serviceAccounts.signBlob
メソッドでは、サービス アカウントのシステムで管理する秘密鍵を使用して blob に署名します。
後述のリクエストのデータを使用する前に、次のように置き換えます。
sa-name
: トークンを作成するサービス アカウントの名前。project-id
: Google Cloud プロジェクト ID。delegates
: 委任されたリクエスト フローを使用している場合は、このページの委任チェーンの指定をご覧ください。委任がない直接リクエスト フローを使用している場合は、リクエスト本文のdelegates
フィールドを省略します。blob-payload
: Base64 でエンコードされたバイトの文字列。例:VGhlIHF1aWNrIGJyb3duIGZveCBqdW1wZWQgb3ZlciB0aGUgbGF6eSBkb2cu
。
HTTP メソッドと URL:
POST https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/sa-name@project-id.iam.gserviceaccount.com:signBlob
JSON 本文のリクエスト:
{ "delegates": [ delegates ], "payload": "blob-payload" }
リクエストを送信するには、次のいずれかのオプションを展開します。
signBlob
リクエストが成功した場合、レスポンスの本文には、署名 blob と blob の署名に使用された署名鍵 ID が含まれています。サービス アカウントの代わりに、signedBlob
値を署名なしトークンとして使用してリクエストを直接認証できます。トークンは、サービス アカウントのシステムで管理する秘密鍵が期限切れになるまで有効です。この鍵の ID はレスポンスの keyId
フィールドの値です。
{ "keyId": "42ba1e...fc0a", "signedBlob": "eyJ0eXAi...NiJ9" }
委任チェーンの指定
委任されたリクエスト フローを使用して有効期間が短いサービス アカウント認証情報を作成する場合、各 API のリクエストの本文で次の形式のサービス アカウントの委任チェーンを正しい順序で指定する必要があります。
projects/-/serviceAccounts/account-email-or-unique-id
たとえば、sa-1
(発信者)から sa-2
(委任)、sa-3
(委任)、sa-4
の順につながる委任チェーンの場合、delegates[]
フィールドには sa-2
と sa-3
が次の順序で含まれます。
{ "delegates": [ "projects/-/serviceAccounts/sa-2@project-id.iam.gserviceaccount.com", "projects/-/serviceAccounts/sa-3@project-id.iam.gserviceaccount.com" ] }
呼び出し元と認証情報が作成されるサービス アカウントは、委任チェーンに含まれません。