サービス アカウント

このページでは、サービス アカウントと Compute Engine の連携について説明します。

サービス アカウントを仮想マシン（VM）インスタンスに接続する手順については、次のいずれかのドキュメントをご覧ください。

サービス アカウントの作成と管理に関するベスト プラクティスについては、サービス アカウントを操作するためのベスト プラクティスのドキュメントをご覧ください。

使ってみる

Google Cloud を初めて使用する場合は、アカウントを作成して、実際のシナリオで Compute Engine のパフォーマンスを評価してください。新規のお客様には、ワークロードの実行、テスト、デプロイができる無料クレジット $300 分を差し上げます。

Compute Engine の無料トライアル

サービス アカウントとは

サービス アカウントは、ユーザーではなく、アプリケーションやコンピューティング ワークロードで使用される特別なアカウントです。サービス アカウントは Identity and Access Management（IAM）で管理されます。

VM でサービス アカウントを使用する場合は、次の点に注意してください。

  • 同じサービス アカウントを複数の VM に接続できますが、1 つの VM に接続できるサービス アカウントは 1 つだけです。
  • 同じサービス アカウントを複数の VM に接続する場合、接続後にサービス アカウントに加える変更は、そのサービス アカウントを使用するすべての VM に影響します。これには、そのサービス アカウントに付与されている IAM ロールに加えた変更も含まれます。たとえばロールを削除すると、サービス アカウントを使用するすべての VM は、そのロールによって付与されている権限を失います。

Compute Engine によるサービス アカウントの使用方法

Compute Engine では、次の 2 種類のサービス アカウントを使用します。

ユーザーが管理するサービス アカウントを Compute Engine インスタンスに接続して、インスタンスで実行されているアプリケーションに認証情報を提供できます。これらの認証情報は、Google Cloud APIs の認証と Google Cloud リソースへのアクセス承認のためにアプリケーションで使用されます。インスタンスに接続できるのはユーザーが管理するサービス アカウントのみで、インスタンスにはサービス アカウントを 1 つだけ接続できます。インスタンスに接続されたサービス アカウントは、作成時または作成後に変更できます。

サービス エージェントは、インスタンスがユーザーに代わって内部プロセスにアクセスするために使用されます。

さらに、各インスタンスに関連付けられたサービス アカウントに基づいて、インスタンスの上り（内向き） / 下り（外向き）トラフィックを許可または拒否するファイアウォール ルールを作成することもできます。

承認の判断方法

Compute Engine インスタンスでホストされているアプリケーションに提供される認可は、接続されているサービス アカウントに付与されるロールとインスタンスに設定するアクセス スコープという 2 つの個別の構成によって制限されます。どちらの構成でも、インスタンスで実行されているアプリケーションがリソースにアクセスできるようにするには、アクセスを許可する必要があります。

Cloud Storage 上のファイルの読み取りと書き込みを行うアプリがある場合は、最初に Cloud Storage API に対する認証を行う必要があります。cloud-platform スコープを持つインスタンスを作成し、インスタンスにサービス アカウントを接続できます。その後、サービス アカウントに Identity and Access Management（IAM）ロールを付与して、アプリに適切なリソースへのアクセス権を付与できます。アプリはサービス アカウントの認証情報を使用して Cloud Storage API に対する認証を行います。インスタンス、イメージ、アプリ コードに秘密鍵やユーザー認証情報を埋め込む必要はありません。また、アプリはサービス アカウントの IAM ロールで提供される認可を使用して、リソースにアクセスします。認可の詳細については、このページの認可をご覧ください。

ユーザーが管理するサービス アカウント

ユーザー管理サービス アカウントには、明示的に作成された新しいサービス アカウントと、Compute Engine のデフォルトのサービス アカウントが挙げられます。

新しいサービス アカウント

IAM を使用して独自のサービス アカウントを作成、管理できます。アカウントを作成したら、アカウントに IAM ロールを付与し、サービス アカウントとして実行されるようにインスタンスを設定します。サービス アカウントが接続されているインスタンスで実行されているアプリは、アカウントの認証情報を使用して他の Google API にリクエストを送信できます。

新しいサービス アカウントを作成して設定するには、ユーザー管理のサービス アカウントを使用する VM を作成するをご覧ください。

Compute Engine のデフォルトのサービス アカウント

Compute Engine API を有効にした新しいプロジェクトには、Compute Engine のデフォルトのサービス アカウントがあり、このアカウントには次のメールアドレスが設定されます。

PROJECT_NUMBER-compute@developer.gserviceaccount.com

Compute Engine のデフォルトのサービス アカウントには次の属性があります。

  • Compute Engine API を有効にすると自動的に作成され、自動生成された名前とメールアドレスが付与され、プロジェクトに追加されます。アカウントはユーザーが完全に制御できます。
  • Google Cloud CLI または Google Cloud コンソールを使用して作成したすべての VM にデフォルトで接続されます。VM の作成時に別のサービス アカウントを指定するか、VM にサービス アカウントを接続しないことを明示的に指定すると、この動作をオーバーライドできます。

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

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

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

このサービス アカウントを無効にしたりプロジェクトから削除したりすることは可能ですが、そうすると、このサービス アカウントの認証情報に依存しているアプリケーションが正しく動作しなくなる可能性があります。Compute Engine のデフォルトのサービス アカウントを誤って削除してしまった場合、30 日以内であればアカウントの復元を試みることができます。詳細については、サービス アカウントの削除と削除取り消しをご覧ください。

Compute Engine のデフォルトのサービス アカウントが削除されてから 30 日以上経過している場合は、デフォルトのサービス アカウントのトラブルシューティングの手順に沿ってサービス アカウントの復元を試みることができます。

サービス エージェント

サービス エージェントは Google Cloud によって作成、管理され、プロジェクトに自動的に割り当てられます。これらのアカウントは複数の Google Cloud サービスに相当し、各アカウントには通常、Google Cloud リソースに対する一定レベルのアクセス権があります。

サービス エージェントを Compute Engine インスタンスに接続することはできません。

Google API サービス エージェント

デフォルトのサービス アカウントは別として、Compute Engine により有効化されたすべてのプロジェクトには、次のメールを使用して識別可能な Google API サービス エージェントが設定されています。

PROJECT_NUMBER@cloudservices.gserviceaccount.com

これは、ユーザーに代わって Google の内部プロセスを実行するために特別に設計されたサービス エージェントです。このサービス エージェントは Google が所有し、Google Cloud コンソールの [サービス アカウント] セクションには表示されません。デフォルトでは、このサービス エージェントには自動的にそのプロジェクトの編集者のロールが付与され、Google Cloud コンソールの [IAM] セクションに表示されます。このサービス エージェントは、プロジェクトが削除された場合にのみ削除されます。ただし、プロジェクトに対するすべてのアクセス権を取り消すなど、このアカウントに付与されているロールを変更することはできます。

一部のリソースは、このサービス エージェントに付与されたデフォルトの編集者権限に依存しています。たとえば、管理対象インスタンス グループと自動スケーリングでは、このサービス エージェントの認証情報を使用して、インスタンスの作成、削除、管理が行われます。このサービス エージェントに対する権限を取り消すか、インスタンスの作成権限を付与しないように権限を変更すると、マネージド インスタンス グループと自動スケーリングが機能しなくなります。

このような理由から、ロールの推奨事項で推奨されていない限り、このサービス エージェントのロールは変更しないようにしてください。

Compute Engine サービス エージェント

Compute Engine API が有効になっているプロジェクトには、Compute Engine サービス エージェントがあります。このサービス エージェントには次のメールアドレスが設定されます。

service-PROJECT_NUMBER@compute-system.iam.gserviceaccount.com

このサービス エージェントは、Compute Engine がプロジェクトでサービス作業を実行するための専用のアカウントとして設計されたものです。これは、Google Cloud プロジェクトに付与されたサービス エージェントの IAM ポリシーに依存しています。また、VM インスタンス上でユーザーが管理するサービス アカウントに Compute Engine がアクセスする際に使用するサービス エージェントでもあります。Google はこのアカウントを所有していますが、このアカウントはプロジェクトに固有のものです。[Google 提供のロール付与を含める] を選択しなければ、このサービス エージェントはコンソールの IAM ページに表示されません。デフォルトでは、このサービス エージェントにはプロジェクトの compute.serviceAgent ロールが自動的に付与されます。

このサービス エージェントは、プロジェクトを削除した場合にのみ削除されます。このサービス エージェントに付与されたロールを変更して、プロジェクトへのすべてのアクセスをこのエージェントから取り消すことができます。このサービス エージェントの権限を取り消すか変更すると、Compute Engine は VM 上のサービス アカウントの ID にアクセスできなくなり、VM 内で実行されているソフトウェアが停止する可能性があります。

このような理由から、このサービス エージェントのロールはできる限り変更しないようにしてください。

サービス アカウントとインスタンスの接続

アプリケーションに過剰な権限を与えることを防ぐため、ユーザーが管理するサービス アカウントを作成してアプリケーションの適切な機能に必要なロールのみを付与し、そのアカウントを Compute Engine インスタンスに接続することをおすすめします。コードでアプリケーションのデフォルト認証情報を使用すると、サービス アカウントが提供する認証情報で認証できます。

サービス アカウントは、インスタンスの作成時またはそれ以降に Compute Engine インスタンスに接続できます。インスタンスに接続できるサービス アカウントは一度に 1 つのみです。サービス アカウントがすでに接続されているインスタンスにサービス アカウントを接続すると、以前のサービス アカウントはそのインスタンスで使用されなくなります。

サービス アカウントを Compute Engine インスタンスに接続する場合は、インスタンスに設定されているスコープが正しいことを確認する必要もあります。スコープが正しくなければ、アプリが必要とするすべての API にアクセスできない場合があります。詳細については、このページのアクセス スコープをご覧ください。

サービス アカウントを Compute Engine インスタンスに接続する手順については、次のいずれかのドキュメントをご覧ください。

認可

サービス アカウントとして実行されるように新しいインスタンスを設定する際には、サービス アカウントに付与する IAM ロールによってサービス アカウントのアクセスレベルを指定します。サービス アカウントに IAM ロールが付与されていない場合、そのインスタンス上でサービス アカウントを使用してリソースにアクセスすることはできません。

さらに、インスタンスのアクセス スコープにより、gcloud CLI およびクライアント ライブラリを使用してインスタンスで行われるリクエストのデフォルトの OAuth スコープが定義されます。このため、OAuth で認証を行う場合は API メソッドへのアクセスがさらに制限される可能性があります。ただし、gRPC など、別の認証プロトコルへの拡張は行われません。

インスタンスで完全な cloud-platform アクセス スコープを設定し、IAM ロールを使用してサービス アカウントのアクセス権を制御することをおすすめします。

以下は基本です。

  • IAM は、サービス アカウントに付与された IAM ロールに基づいて API へのアクセスを制限します。
  • アクセス スコープにより、API メソッドへのアクセスがさらに制限される可能性があります。

アクセス スコープと IAM ロールについては、以降のセクションで詳しく説明します。

IAM ロール

関連する API メソッドへのアクセスをサービス アカウントに許可するには、該当する IAM ロールをサービス アカウントに付与する必要があります。

たとえば、Cloud Storage オブジェクトの管理や Cloud Storage バケットの管理などを行うための IAM ロールをサービス アカウントに付与し、それらのロールによって付与される権限にアカウントの権限を制限できます。

サービス アカウントに IAM ロールを付与すると、そのサービス アカウントが接続されているインスタンスで実行されるアプリケーションには、そのロールによって付与される承認が割り当てられます。

次の点に注意してください。

  • 一部の IAM ロールはベータ版です。

    必要なアクセスレベルを備えた事前定義済みのロールがない場合は、カスタムロールを作成して付与できます。

  • インスタンスにアクセス スコープを設定して、アクセス権限を承認する必要があります。

    サービス アカウントのアクセスレベルはそのサービス アカウントに付与されたロールによって決まりますが、インスタンスのアクセス スコープによって、gcloud CLI とクライアント ライブラリを使用してインスタンスで行われるリクエストのデフォルトの OAuth スコープが定義されます。このため、OAuth で認証を行う場合は API メソッドへのアクセスがさらに制限される可能性があります。

アクセス スコープ

アクセス スコープは、VM インスタンスの認可を指定する以前の方法です。gcloud CLI またはクライアント ライブラリからのリクエストで使用されるデフォルトの OAuth スコープを定義します。アクセス スコープは、gRPC を使用して行われる呼び出しには適用されません。

アクセス スコープは VM 単位で適用され、VM の存続期間中のみ保持されます。アクセス スコープは、VM の作成時または既存の VM のアクセス スコープの更新時に設定できます。

一般に、API メソッドのドキュメントには、そのメソッドで必要なスコープも記載されています。たとえば、instances.insert メソッドの場合、有効なスコープのリストが authorization セクションで指定されます。

サービス アカウントが属するプロジェクトで関連 API が無効になっている場合、アクセス スコープは適用されません。たとえば、仮想マシン インスタンスに Cloud Storage のアクセス スコープを付与すると、インスタンスは、プロジェクトで Cloud Storage API が有効になっている場合にのみ Cloud Storage API を呼び出すことができます。

デフォルトのスコープ

新しい Compute Engine インスタンスを作成すると、次のアクセス スコープが自動的に構成されます。

  • Cloud Storage への読み取り専用アクセス権:
    https://www.googleapis.com/auth/devstorage.read_only
  • Compute Engine ログに書き込むための書き込みアクセス権:
    https://www.googleapis.com/auth/logging.write
  • Google Cloud プロジェクトに指標データを公開するための書き込みアクセス権:
    https://www.googleapis.com/auth/monitoring.write
  • Google Cloud Endpoints に必要な Service Management 機能に対する読み取り専用アクセス権（アルファ版）:
    https://www.googleapis.com/auth/service.management.readonly
  • Google Cloud Endpoints に必要な Service Control 機能に対する読み取り / 書き込みアクセス権（アルファ版）:
    https://www.googleapis.com/auth/servicecontrol
  • Cloud Trace への書き込みアクセス権。VM 上で実行されているアプリケーションがトレースデータをプロジェクトに書き込むことができます。
    https://www.googleapis.com/auth/trace.append

スコープのベスト プラクティス

使用可能なアクセス スコープは多数ありますが、ベスト プラクティスは cloud-platform アクセス スコープを設定することです。これは、Google Cloud サービスの OAuth スコープです。サービス アカウントに IAM ロールを付与し、サービス アカウントのアクセス権を制御できます。

https://www.googleapis.com/auth/cloud-platform

スコープの例

スコープのベスト プラクティスに従って、インスタンスで cloud-platform アクセス スコープを有効にして次の事前定義された IAM ロールを付与したとします。

  • roles/compute.instanceAdmin.v1
  • roles/storage.objectViewer
  • roles/compute.networkAdmin

この場合、サービス アカウントには、この 3 つのロールに含まれる権限のみが付与されます。そのサービス アカウントの権限を借用するアプリケーションは、Google Cloud のアクセス スコープに関係なく、これらのロールのスコープ外のアクションは実行できません。

逆に、Cloud Storage の読み取り専用スコープ（https://www.googleapis.com/auth/devstorage.read_only）など、より制限の厳しいスコープをインスタンスに付与し、サービス アカウントに roles/storage.objectAdmin 管理者ロールを設定すると、デフォルトでは、サービス アカウントに roles/storage.ObjectAdmin ロールを付与しても、そのインスタンスからは gcloud CLI やクライアント ライブラリからのリクエストで Cloud Storage オブジェクトを管理することはできません。これは、Cloud Storage の読み取り専用スコープでは、インスタンスが Cloud Storage データを操作することは認められないためです。

アクセス スコープの例は次のとおりです。

  • https://www.googleapis.com/auth/cloud-platform。指定した Google Cloud プロジェクト内の Google Cloud サービス全体のデータを表示して管理します。
  • https://www.googleapis.com/auth/compute。Compute Engine メソッドに対するフル コントロール アクセス権。
  • https://www.googleapis.com/auth/compute.readonly。Compute Engine メソッドに対する読み取り専用アクセス権。
  • https://www.googleapis.com/auth/devstorage.read_only。Cloud Storage に対する読み取り専用アクセス権。
  • https://www.googleapis.com/auth/logging.write。Compute Engine ログに対する書き込みアクセス権。

次のステップ