サービス ID の概要

このページでは、Cloud Run の 2 つの ID についてと、Cloud クライアント ライブラリがサービス ID を使用して Google Cloud APIs を呼び出す方法について説明します。Cloud クライアント ライブラリが組み込まれている Google Cloud プロダクトの例としては、Cloud Storage、Firestore、Cloud SQL、Pub/Sub、Cloud Tasks などがあります。このページは、組織のポリシーとユーザー アクセスを管理する管理者、オペレーター、デベロッパー、またはそのようなトピックについて学習したいユーザーを対象としています。

Cloud Run の ID

Cloud Run を使用するには、Google Cloud で Cloud Run ユーザーと Cloud Run インスタンスの ID が必要です。

  • Cloud Run ユーザーの ID は、Cloud Run デプロイ担当者アカウントと呼ばれます。リビジョンまたはジョブを管理する際に、この ID を使用して Cloud Run Admin API にリクエストを送信します。
  • Cloud Run インスタンスの ID は、Cloud Run サービス ID と呼ばれます。作成した Cloud Run コードが Cloud クライアント ライブラリと通信する場合、またはサービス間の通信のために別の Cloud Run サービスを呼び出す場合は、この ID を使用して Cloud Run から Google Cloud APIs またはその他の Cloud Run サービスにリクエストを送信します。

Google Cloud APIs にアクセスしてリクエストを送信したり、サービス間で通信したりするには、それぞれの ID に Identity and Access Management（IAM）で適切な権限が付与されている必要があります。

デプロイ担当者アカウントを使用して Cloud Run Admin API を呼び出す

Cloud Run から Cloud Run Admin API を呼び出す際に Cloud Run デプロイ担当者アカウントを使用できます。デプロイ担当者アカウントはユーザー アカウントまたはサービス アカウントのいずれかで、Google Cloud 環境にログインしたアカウントになります。

デプロイ担当者アカウントが Cloud Run を使用する前に、IAM はデプロイ担当者アカウントに Cloud Run オペレーションの実行に必要な権限があるかどうかを確認します。次の図は、ユーザー アカウントが Cloud Run Admin API を呼び出して、Google Cloud コンソールから新しいリビジョンをデプロイする方法を示しています。

Google Cloud コンソールから Cloud Run Admin API を呼び出す。
図 1. ユーザーが新しいリビジョンをデプロイするために、Google Cloud コンソールを使用して、アクセス トークンを含むリクエストを Cloud Run Admin API に送信します。オペレーションを実行する前に、IAM はそのアクセス トークンを使用してユーザー アカウントの認証を行い、Cloud Run Admin API へのアクセスが許可されているかどうか確認します。

サービス ID を使用して Google Cloud APIs を呼び出す

Cloud Run インスタンスが他の IAM 認証済み Cloud Run サービスと通信する場合、またはアプリケーション コードまたは組み込み機能（Cloud Run インテグレーションや Cloud Storage ボリューム マウントなど）を介して Cloud Client ライブラリを呼び出す場合、Google Cloud 環境はアプリケーションのデフォルト認証情報（ADC）を使用して Cloud Run のサービス ID の認証を行い、API オペレーションの実行が許可されているかどうかを自動的に確認します。Cloud Run のサービス ID は、リビジョンのデプロイまたはジョブの実行時に Cloud Run インスタンスの ID として割り当てられたサービス アカウントです。

デプロイ担当者アカウントとして使用されるサービス アカウントは、Cloud Run 構成で同じサービス アカウントが構成されている場合にのみ、サービス ID としても使用されます。

このガイドの残りの部分では、Cloud Run サービスまたはジョブがサービス ID を使用して Google サービスと API を呼び出し、アクセスする方法について説明します。サービス ID の構成の詳細については、サービスとジョブのサービス ID の構成ページをご覧ください。

サービス ID のサービス アカウントの種類

Cloud Run インスタンスが Google Cloud APIs を呼び出して必要なオペレーションを実行する際に、Cloud Run はサービス ID としてサービス アカウントを自動的に使用します。サービス ID として使用できるサービス アカウントには次の 2 種類があります。

  • ユーザー管理のサービス アカウント（推奨）: このサービス アカウントは手動で作成します。特定の Google Cloud リソースにアクセスするためにサービス アカウントが必要とする最小限の権限を付与します。ユーザー管理のサービス アカウントの形式は SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com です。
  • Compute Engine のデフォルト サービス アカウント: Cloud Run は、デフォルトのサービス ID として Compute Engine のデフォルト サービス アカウントを自動的に提供します。Compute Engine のデフォルト サービス アカウントの形式は PROJECT_NUMBER-compute@developer.gserviceaccount.com です。

サービス ID の構成時にデフォルト サービス アカウントを使用しない

デフォルトでは、Compute Engine のデフォルトのサービス アカウントが自動的に作成されます。Cloud Run サービスまたはジョブの作成時にサービス アカウントを指定しないと、Cloud Run はこのサービス アカウントを使用します。

組織のポリシーの構成によっては、デフォルトのサービス アカウントにプロジェクトの編集者のロールが自動的に付与される場合があります。iam.automaticIamGrantsForDefaultServiceAccounts 組織ポリシー制約を適用して、自動的なロール付与を無効にすることを強くおすすめします。2024 年 5 月 3 日以降に組織を作成した場合、この制約はデフォルトで適用されます。

自動ロール付与を無効にする場合、デフォルトのサービス アカウントに付与するロールを決定し、これらのロールを付与する必要があります。

デフォルトのサービス アカウントにすでに編集者ロールが設定されている場合は、編集者ロールを権限の低いロールに置き換えることをおすすめします。サービス アカウントのロールを安全に変更するには、Policy Simulator を使用して変更の影響を確認してから、適切なロールを付与または取り消す操作を行います。

サービス ID の機能

コードから Cloud Client ライブラリを呼び出したり、リクエストを送信したりすると、次の処理が行われます。

  1. クライアント ライブラリが、Google Cloud APIs または Cloud クライアント ライブラリに対するリクエストを検出し、インスタンス メタデータ サーバーにサービス ID の OAuth 2.0 アクセス トークンをリクエストします。
  2. インスタンス メタデータ サーバーが、サービス ID として構成されたサービス アカウントの IAM アクセス トークンを返します。
  3. Google Cloud APIs に対するリクエストは、OAuth 2.0 アクセス トークンとともに送信されます。
  4. IAM が、アクセス トークンで参照されているサービス ID に必要な権限があるかどうかを検証し、API エンドポイントに呼び出しを転送する前にポリシー バインディングを確認します。
  5. Google Cloud APIs がオペレーションを実行します。
Cloud Run から Google Cloud API を呼び出す。
図 1. IAM は、Cloud Run がメタデータ サーバーから生成したアクセス トークンを使用して、割り当てられた Cloud Run サービス ID の認証を行い、Google Cloud APIs へのアクセスが許可されているかどうか確認します。

Google Cloud APIs を呼び出す Cloud Run リクエストにアクセス トークンを生成する

Cloud Run コードで Cloud クライアント ライブラリを使用する場合は、デプロイ時または実行時にサービス アカウントを割り当て、Cloud Run でサービス ID を構成します。これにより、ライブラリはアクセス トークンを自動的に取得し、コードのリクエストの認証を行います。Cloud Run コードが他の認証済み Cloud Run サービスと通信する場合は、リクエストにアクセス トークンを追加する必要があります。

サービス ID としてサービス アカウントを割り当てる場合は、次のガイドをご覧ください。

ただし、独自のカスタムコードを使用する場合や、プログラムでリクエストを行う必要がある場合は、直接メタデータ サーバーを使用して、次のセクションで説明する ID トークンとアクセス トークンを手動で取得できます。メタデータ サーバーは、Google Cloud 上で実行されるワークロードでのみ使用できます。ローカルマシンから直接このサーバーにクエリを実行することはできません。

メタデータ サーバーから ID トークンとアクセス トークンを取得する

メタデータ サーバーから取得できるトークンには、次の 2 種類があります。

使用しているトークンの種類のタブを開いて、トークンの取得手順を確認してください。

アクセス トークン

たとえば、Pub/Sub トピックを作成する場合は、projects.topics.create メソッドを使用します。

  1. アクセス トークンを取得するには、Compute Metadata Server を使用します。

    curl "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token" \
    --header "Metadata-Flavor: Google"

    このエンドポイントは、access_token 属性を含む JSON レスポンスを返します。

  2. HTTP プロトコルのリクエストでは、Authorization ヘッダーに含まれるアクセス トークンでリクエストの認証を受ける必要があります。

    PUT https://pubsub.googleapis.com/v1/projects/PROJECT_ID/topics/TOPIC_ID
Authorization: Bearer ACCESS_TOKEN

    ここで

    • PROJECT_ID はプロジェクト ID です。
    • TOPIC_ID はトピック ID です。
    • ACCESS_TOKEN は、前の手順で取得したアクセス トークンです。

    レスポンス:

    {
    "name": "projects/PROJECT_ID/topics/TOPIC_ID"
}

ID トークン

特定のユーザーの ID トークンを取得するには、Compute Metadata Server を使用します。

curl "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=AUDIENCE" \
    --header "Metadata-Flavor: Google"

ここで、AUDIENCE は、リクエストされた JWT オーディエンスです。

Cloud Run サービスの場合、オーディエンスは、呼び出すサービスの URL かカスタム オーディエンス（サービス用に構成されたカスタム ドメインなど）である必要があります。

https://service.domain.com

他のリソースでは、IAP で保護されたリソースの OAuth クライアント ID の場合もあります。

1234567890.apps.googleusercontent.com

次のステップ