サービス アカウントをリソースに関連付ける

一部の Google Cloud リソースでは、リソースがデフォルトの ID として使用するユーザー管理のサービス アカウントを指定できます。このプロセスは、サービス アカウントをリソースに「接続する」、またはサービス アカウントとリソースを「関連付ける」といいます。リソースで実行されているコードが Google Cloud のサービスとリソースにアクセスすると、そのリソースに関連付けられているサービス アカウントが ID として使用されます。たとえば、サービス アカウントを Compute Engine インスタンスに接続し、そのインスタンスのアプリケーションがクライアント ライブラリを使用して Google Cloud APIs を呼び出す場合、これらのアプリケーションは、認証と認可に接続されたサービス アカウントを自動的に使用します。

このページでは、サービス アカウントを構成して、リソースと接続できるようにする方法について説明します。

始める前に

  • Enable the IAM and Resource Manager APIs.

    Roles required to enable APIs

    To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

    Enable the APIs

  • IAM のサービス アカウントの仕組みを理解しておく必要があります。

必要なロール

サービス アカウントをリソースに関連付けるために必要な権限を取得するには、サービス アカウントに対するサービス アカウント ユーザー（roles/iam.serviceAccountUser）IAM ロールを付与するよう管理者に依頼してください。ロールの付与については、プロジェクト、フォルダ、組織へのアクセスを管理するをご覧ください。

この事前定義ロールには、サービス アカウントをリソースに関連付けるために必要な iam.serviceAccounts.actAs 権限が含まれています。

カスタムロールや他の事前定義ロールを使用して、この権限を取得することもできます。

組織のポリシーを構成する

リソースに関連付けるサービス アカウントの場所によっては、サービス アカウントを関連付ける前に、プロジェクトの組織のポリシーの更新が必要になる場合があります。

サービス アカウントを構成する

サービス アカウントは、リソースに関連付ける前に構成する必要があります。このプロセスは、サービス アカウントとリソースが同じプロジェクト内にあるか、または異なるプロジェクトにあるかによって異なります。サービス アカウントの構成後、リソースを作成してサービス アカウントを接続できます。

同じプロジェクト内のリソースを構成する

同じプロジェクト内の別のリソースにサービス アカウントを接続する前に、他のプリンシパルにロールを付与する場合と同様に、サービス アカウントにロールを付与して、適切なリソースにアクセスできるようにします。

異なるプロジェクトのリソースを構成する

場合によっては、別のプロジェクトに配置されているリソースにサービス アカウントを接続する必要が生じる可能性があります。たとえば、1 つのプロジェクト内にすべてのサービス アカウントを作成する場合には、それらのアカウントの 1 つを別のプロジェクトの新しいリソースに接続する必要が生じる可能性があります。

サービス アカウントを別のプロジェクトのリソースに接続する前に、次のことを実施します。

  1. サービス アカウントが存在するプロジェクトで、このページの手順に沿ってサービス アカウントをプロジェクト間で接続できるようにします。
  2. リソースを作成するプロジェクトを特定します。

  3. サービス アカウントを接続するリソースのタイプと、そのタイプのリソースを所有するサービスを特定します。

    たとえば、Pub/Sub サブスクリプションを作成する場合、Pub/Sub はリソースを所有するサービスです。

  4. そのサービスを提供するサービス エージェントのメールアドレスを検索します。

    サービスによって、使用するサービス エージェントが異なります。詳細については、サービス エージェントをご覧ください。

  5. サービス エージェントにサービス アカウント トークン作成者のロール（roles/iam.serviceAccountTokenCreator）を付与します。

    コンソール

    1. Google Cloud コンソールで、[サービス アカウント] ページに移動します。

      [サービス アカウント] に移動

    2. リソースに接続するサービス アカウントを所有するプロジェクトを選択します。

    3. リソースに関連付けるサービス アカウントのメールアドレスをクリックします。

    4. [アクセス権を持つプリンシパル] タブに移動します。

    5. [ アクセス権を付与] をクリックし、サービス エージェントのメールアドレスを入力します。

    6. [ロールを選択] をクリックし、「Service Account Token Creator」と入力してロールをクリックします。

    7. [保存] をクリックして、変更を保存します。

    8. 省略可: 別のサービス エージェントにロールを付与する必要がある場合は、上記の手順を繰り返します。

    gcloud

    gcloud iam service-accounts add-iam-policy-binding コマンドを実行します。

    gcloud iam service-accounts add-iam-policy-binding \
    SERVICE_ACCOUNT_NAME@PROJECT_ID. \
    --member=serviceAccount:SERVICE_AGENT_EMAIL \
    --role=roles/iam.serviceAccountTokenCreator

    次の値を置き換えます。

    • SERVICE_ACCOUNT_NAME: リソースに接続するユーザー管理のサービス アカウントの名前。
    • PROJECT_ID: ユーザー管理のサービス アカウントが存在するプロジェクト ID。
    • SERVICE_AGENT_EMAIL: サービス エージェントのメールアドレス。

    このコマンドでは、ユーザー管理のサービス アカウントの更新済みの許可ポリシーが出力されます。

    省略可: 別のサービス エージェントにロールを付与する必要がある場合は、コマンドを再度実行します。

    REST

    このロールを付与するには、読み取り - 変更 - 書き込みパターンを使用して、ユーザー管理のサービス アカウントの許可ポリシーを更新します。

    まず、ユーザー管理のサービス アカウントの許可ポリシーを読み取ります。

    projects.serviceAccounts.getIamPolicy メソッドは、サービス アカウントの許可ポリシーを返します。

    リクエストのデータを使用する前に、次のように置き換えます。

    • PROJECT_ID: 実際の Google Cloud プロジェクト ID。プロジェクト ID は英数字からなる文字列です（例: my-project）。
    • USER_SA_NAME: リソースにバインドするユーザー管理のサービス アカウントの名前。

    HTTP メソッドと URL:

    POST https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts/USER_SA_NAME@PROJECT_ID.:getIamPolicy

    リクエストの本文（JSON）: 

    {
  "requestedPolicyVersion": 3
}

    リクエストを送信するには、次のいずれかのオプションを展開します。

    次のような JSON レスポンスが返されます。

    {
  "version": 1,
  "etag": "BwWl3KCTUMY=",
  "bindings": [
    {
      "role": "roles/iam.serviceAccountUser",
      "members": [
        "serviceAccount:my-service-account@my-project."
      ]
    }
  ]
}

    次に、許可ポリシーを変更して、サービス エージェントにサービス アカウント トークン作成者のロールを付与します。

    {
  "version": 1,
  "etag": "BwWl3KCTUMY=",
  "bindings": [
    {
      "role": "roles/iam.serviceAccountTokenCreator",
      "members": [
        "serviceAccount:SERVICE_AGENT_EMAIL"
      ]
    },
    {
      "role": "roles/iam.serviceAccountUser",
      "members": [
        "serviceAccount:SERVICE_ACCOUNT_NAME@PROJECT_ID."
      ]
    }
  ]
}

    次のように置き換えます。

    • SERVICE_AGENT_EMAIL: サービス エージェントのメールアドレス。
    • SERVICE_ACCOUNT_NAME: ユーザー管理のサービス アカウントの名前。
    • PROJECT_ID: ユーザー管理のサービス アカウントが存在するプロジェクト ID。

    最後に、更新された許可ポリシーを作成します。

    projects.serviceAccounts.setIamPolicy メソッドは、サービス アカウントの許可ポリシーを更新します。

    リクエストのデータを使用する前に、次のように置き換えます。

    • PROJECT_ID: 実際の Google Cloud プロジェクト ID。プロジェクト ID は英数字からなる文字列です（例: my-project）。
    • USER_SERVICE_ACCOUNT_NAME: リソースにバインドするユーザー管理のサービス アカウントの名前。
    • SERVICE_AGENT_EMAIL: ユーザー管理のサービス アカウントのアクセス トークンを作成するサービス エージェントのメールアドレス。

    HTTP メソッドと URL:

    POST https://iam.googleapis.com/v1/projects/PROJECT_ID/serviceAccounts/SERVICE_ACCOUNT_NAME@PROJECT_ID.:setIamPolicy

    リクエストの本文（JSON）: 

    {
  "policy": {
    "version": 1,
    "etag": "BwWl3KCTUMY=",
    "bindings": [
      {
        "role": "roles/iam.serviceAccountTokenCreator",
        "members": [
          "serviceAccount:SERVICE_AGENT_EMAIL"
        ]
      },
      {
        "role": "roles/iam.serviceAccountUser",
        "members": [
          "serviceAccount:SERVICE_ACCOUNT_NAME@PROJECT_ID."
        ]
      }
    ]
  }
}

    リクエストを送信するには、次のいずれかのオプションを展開します。

    次のような JSON レスポンスが返されます。

    {
  "version": 1,
  "etag": "BwWo331TkHE=",
  "bindings": [
    {
      "role": "roles/iam.serviceAccountTokenCreator",
      "members": [
        "serviceAccount:SERVICE_AGENT_EMAIL"
      ]
    },
    {
      "role": "roles/iam.serviceAccountUser",
      "members": [
        "serviceAccount:my-service-account@my-project."
      ]
    }
  ]
}

サービス アカウントをリソースに関連付ける

ユーザー管理のサービス アカウントの構成後、新しいリソースを作成してサービス アカウントを関連付けることができます。新しいリソースは、適切なプロジェクトで作成するようにしてください。

ほとんどの場合、リソースの作成時にリソース アカウントをサービス アカウントに関連付ける必要があります。リソースの作成後に、リソースに関連付けられているサービス アカウントを変更することはできません。Compute Engine インスタンスは例外です。必要に応じて、インスタンスに関連付けるサービス アカウントを変更できます。

作成するリソースの種類に応じた手順をご覧ください。

リソースの作成時にサービス アカウントを接続する
Compute Engine
Google Kubernetes Engine
Pub/Sub 登録

リソースを作成してそのリソースにサービス アカウントを関連付けると、適切なリソースにアクセスできるようにサービス アカウントにロールを付与できます。このプロセスは、他のプリンシパルにロールを付与する場合と同じです。

ロールを付与する方法については、リソースへのアクセス権の付与、変更、取り消しをご覧ください。

プロジェクト間でのサービス アカウントの関連付けを有効にする

あるプロジェクトのサービス アカウントを別のプロジェクトのリソースに関連付けるには、サービス アカウントを含むプロジェクトの組織のポリシーを更新する必要があります。そのプロジェクトの組織のポリシーで、次のブール型制約を確認します。

  • iam.disableCrossProjectServiceAccountUsage ブール型制約はプロジェクトに適用しないようにしてください。

    このブール型制約は、サービス アカウントを別のプロジェクトのリソースに接続できるかどうかを制御します。これはデフォルトで適用され、フォルダレベルや組織レベルではなく、プロジェクト レベルでのみ構成できます。

    この制約が適用されていない場合は、プロジェクトの削除を防止するプロジェクト リーエンが IAM によって追加されます。このリーエンは元の iam.googleapis.com/cross-project-service-accounts を持ちます。このリーエンは削除しないことを強くおすすめします。

  • 推奨: iam.restrictCrossProjectServiceAccountLienRemoval ブール型制約がプロジェクトに適用されていることを確認してください。

    このブール型制約は、組織レベルで resourcemanager.projects.updateLiens 権限を付与されている場合にのみ、プリンシパルがプロジェクト リーエンを削除できるようにします。この制約が適用されていない場合、プリンシパルはプロジェクト レベルでこの権限があればプロジェクト リーエンを削除できます。

組織のポリシーのブール型制約を確認、変更する方法については、組織のポリシーの作成と管理をご覧ください。

プロジェクト間でのサービス アカウントの接続を無効にする

以前にプロジェクト間のサービス アカウントの関連付けを有効にした場合、特に本番環境では、この機能を無効しないことを強くおすすめします。

具体的には、サービス アカウントが存在するプロジェクトで次のような変更を行うことは推奨されません。

  • iam.disableCrossProjectServiceAccountUsage ブール型制約を適用するようにプロジェクトの組織のポリシーを更新することは控える。
  • iam.restrictCrossProjectServiceAccountLienRemoval ブール型制約を適用しないようにプロジェクトの組織ポリシーを更新することは控える。
  • 元の iam.googleapis.com/cross-project-service-accounts があるプロジェクト リーエンの削除は控える。こうすることでプロジェクトの削除を防止できます。
  • プロジェクトの削除は控える。

この機能を無効にすることで発生するリスクをとる場合、そのリスクを軽減するには、プロジェクト間で使用しているサービス アカウントを無効にし、問題が生じないかどうか、 Google Cloud 環境をモニタリングします。問題が見つかった場合は、サービス アカウントを再度有効にできます。問題が生じない場合は、別のプロジェクトのサービス アカウントに依存する Google Cloudリソースが存在しないことが考えられます。

サービス アカウントの接続に関する監査ログ

プリンシパルが iam.serviceAccounts.actAs 権限を使用してサービス アカウントをリソースに接続すると、IAM は監査ログを生成します。この監査ログには、次の情報が含まれます。

  • サービス アカウントをリソースに接続したプリンシパルのメールアドレス
  • リソースに接続されたサービス アカウントの詳細

サービス アカウントを接続できるリソースの一覧については、このページのサービス アカウントを新しいリソースに接続するをご覧ください。

このタイプの監査ログの例については、iam.serviceAccounts.actAs 権限の使用に関するログをご覧ください。監査ログの一般的な詳細については、Cloud Audit Logs の概要をご覧ください。

次のステップ