サービス アカウント

このページでは、サービス アカウント、サービス アカウントの種類、サービス アカウントで使用できる IAM のロールについて説明します。

始める前に

  • IAM の基本コンセプトについて理解しておきます。

サービス アカウントとは

サービス アカウントは、ユーザーではなく、アプリケーションや仮想マシン(VM)インスタンスで使用される特別なアカウントです。アプリケーションはサービス アカウントを使用して、承認された API 呼び出しを行います。これは、サービス アカウント自体として承認されるか、ドメイン全体の委任により Google Workspace または Cloud Identity ユーザーとして承認されます。

たとえば、あるサービス アカウントで Compute Engine VM が実行される場合、必要なリソースへのアクセス権をそのアカウントに付与できます。こうしてサービス アカウントはサービスの ID となり、サービス アカウントの権限はサービスがアクセスできるリソースを制御します。

サービス アカウントは、アカウント固有のメールアドレスで識別されます。

サービス アカウントとユーザー アカウントの違い

サービス アカウントは、いくつかの重要な点がユーザー アカウントと異なります。

  • サービス アカウントにはパスワードがなく、ブラウザやクッキーでログインできません。
  • サービス アカウントは、Google への認証に使用される秘密 / 公開 RSA 鍵ペアに関連付けられています。
  • あるサービス アカウントの代わりとして、他のユーザーまたは他のサービス アカウントを使用することができます。
  • ユーザー アカウントとは異なり、サービス アカウントは Google Workspace ドメインのメンバーではありません。Google Workspace のアセット(ドキュメントやイベントなど)を Google Workspace ドメインのすべてのメンバーと共有しても、サービス アカウントとは共有されません。同様に、サービス アカウントによって作成された Google Workspace アセットは、Google Workspace ドメインには作成されません。そのため、Google Workspace と Cloud Identity 管理者はこれらのアセットを所有、管理することはできません。

サービス アカウント キー

各サービス アカウントは、Google への認証に使用される 2 組の公開 / 秘密 RSA 鍵ペア(Google が管理するキーとユーザーが管理するキー)に関連付けられています。

Google が管理するキー

Google が管理する鍵ペアでは、公開部分と秘密部分の両方を Google が保存し、定期的にローテーションします(各鍵は最大 2 週間、署名に使用できます)。秘密鍵は常にエスクローに保管され、直接アクセスされることはありません。IAM では、これらの鍵を使用してサービス アカウントの代わりに署名する API が提供されています。詳しくは、有効期間が短いサービス アカウント認証情報の作成をご覧ください。

ユーザーが管理するキー

ユーザーが管理する鍵ペアを作成することは、鍵ペアの公開部分と秘密部分の両方を所有することを意味します。Google Cloud の外部から使用できるユーザー管理の鍵ペア(外部キー)を 1 つまたは複数作成できます。Google では、ユーザーが管理する鍵の公開部分のみを格納します。

さらに、適切な形式の公開鍵を作成して Google にアップロードすると、指定されたサービス アカウントに対して恒久的に関連付けられます。サービス アカウント キーの作成時など、そのサービス アカウントに代わって署名操作を行う必要がある場合は、アップロードされた公開鍵が使用されます。

ユーザーが管理する鍵ペアの秘密部分は、アプリケーションのデフォルト認証情報で使用されるのが最も一般的です。この秘密鍵は、サーバー間アプリケーションの認証に使用されます。

ユーザーが管理するキーの場合、秘密鍵のセキュリティや、鍵のローテーションなどの他の管理オペレーションを行います。ユーザーが管理するキーは、IAM API、gcloud コマンドライン ツール、Google Cloud Console の [サービス アカウント] ページで管理できます。サービス アカウントごとに最大 10 個のサービス アカウント キーを作成できるので、鍵のローテーションが容易になります。

鍵を安全に管理するため、Cloud Key Management Service(Cloud KMS)の使用を検討してください。

ユーザーが管理するキーを制限する

ユーザーが管理する鍵は非常に強力な認証情報であり、正しく管理しなければセキュリティ上のリスクとなります。

ユーザーが管理する鍵の使用を制限するには、次の組織のポリシーの制約を組織、プロジェクト、フォルダに適用します。

  • constraints/iam.disableServiceAccountKeyCreation: メンバーがユーザー管理のサービス アカウント キーを作成できないようにします。
  • constraints/iam.disableServiceAccountKeyUpload: メンバーがサービス アカウントの公開鍵をアップロードできないようにします。

サービス アカウントのタイプ

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

IAM API、Cloud Console、または gcloud コマンドライン ツールを使用して、ユーザーが管理するサービス アカウントをプロジェクトに作成できます。これらのアカウントの管理と保護は、お客様の責任となります。

デフォルトでは、1 つのプロジェクトに最大 100 個のユーザー管理サービス アカウントを作成できます。この割り当てがニーズを満たしていない場合は、Cloud Console を使用して割り当ての増加をリクエストできます。このページで説明するデフォルトのサービス アカウントは、この割り当てのカウントには含められません。

プロジェクトでユーザー管理サービス アカウントを作成するときには、サービス アカウントの名前を選んでください。この名前は、サービス アカウントを識別するメールアドレスに次の形式で表示されます。

service-account-name@project-id.iam.gserviceaccount.com

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

一部の Google Cloud サービスを有効にするか使用するときにはユーザー管理サービス アカウントが作成されます。このアカウントにより、サービスは他の Google Cloud リソースにアクセスするジョブをデプロイできます。これらのアカウントはデフォルトのサービス アカウントと呼ばれます。

デフォルトのサービス アカウントがある Google Cloud 環境内でアプリケーションが実行される場合、アプリケーションはデフォルトのサービス アカウントの認証情報を使用して Google Cloud APIs を呼び出すことができます。または、独自のユーザー管理サービス アカウントを作成し、そのアカウントを使用して認証することもできます。詳細については、認証情報の自動検出をご覧ください。

次の表に、デフォルト サービス アカウントを作成するサービスを示します。

サービス サービス アカウント名 メールアドレス
App Engine、および App Engine を使用する Google Cloud サービス App Engine デフォルト サービス アカウント project-id@appspot.gserviceaccount.com
Compute Engine、および Compute Engine を使用する Google Cloud サービス Compute Engine のデフォルトのサービス アカウント project-number-compute@developer.gserviceaccount.com

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

一部の Google Cloud サービスは、ユーザーに代わって処理を行うためにリソースにアクセスする必要があります。たとえば、Cloud Run でコンテナを実行する場合、このサービスはコンテナをトリガーする Pub/Sub トピックにアクセスする必要があります。

このニーズに応えるために、Google では多くの Google Cloud サービスにサービス アカウントを作成し、管理しています。これらのサービス アカウントは、Google が管理するサービス アカウントといいます。プロジェクトの IAM ポリシー、監査ログ、または Cloud Console の IAM ページに、Google が管理するサービス アカウントが表示されることがあります。

例:

  • Google API サービス エージェント多くの場合、プロジェクトには Google API サービス エージェントという名前のサービス アカウントが含まれています。このメールアドレスは project-number@cloudservices.gserviceaccount.com という形式になります。

    このサービス アカウントは内部の Google プロセスを実行します。これには、プロジェクトに対する編集者ロール(roles/editor)が自動的に付与されます。

  • Google が管理するサービス アカウントのロール マネージャー。IAM の監査ログにサービス アカウント service-agent-manager@system.gserviceaccount.com が示される場合があります。

    このサービス アカウントは、他の Google が管理するサービス アカウントに付与されているロールを管理します。これは監査ログにのみ表示されます。

    たとえば、新しい API を使用する場合、Google によって新しい Google 管理のサービス アカウントが自動的に作成され、プロジェクトのサービス アカウントにロールを付与することがあります。これらのロールを付与すると、監査ログエントリが生成されます。これは、service-agent-manager@system.gserviceaccount.com がプロジェクトの IAM ポリシーを設定していることを示しています。

  • Google が管理するその他のサービス アカウント。プロジェクトには、個々のサービスの代理として機能する Google 管理のサービス アカウントが含まれる場合があります。これらのサービス アカウントは、サービス エージェントということもあります。これらのサービス エージェントにロールが自動的に付与される場合があります。通常、これらのロール名の最後には serviceAgent が付いています。

    サービス エージェントと、それらに自動的に付与されるロールの一覧については、サービス エージェントをご覧ください。

サービス アカウントの場所

各サービス アカウントはプロジェクト内にあります。サービス アカウントは、作成後、別のプロジェクトに移動することはできません。

サービス アカウントをプロジェクトにまとめるには、いくつかの方法があります。

  • 同じプロジェクトにサービス アカウントとリソースを作成する。

    この手法を使用すると、サービス アカウントを簡単に使い始めることができます。ただし、多数のプロジェクトにまたがるサービス アカウントを追跡するのは困難な場合があります。

  • サービス アカウントを別のプロジェクトで一元管理する。

    この手法では、他のプロジェクトのリソースにサービス アカウントを関連付けるときに追加の設定を行う必要があります。これにより、リソースが ID としてサービス アカウントを使用できるようになります。また一方で、この手法を使用すると、すべてのサービス アカウントが同じ場所に存在するようになるため、組織のサービス アカウントを管理しやすくなります。

    デフォルトでは、プロジェクト内に最大 100 個のサービス アカウントを作成できます。追加のサービス アカウントを作成する必要がある場合は、割り当ての増加をリクエストします。

サービス アカウント権限

サービス アカウントは、ID であると同時にリソースでもあります。

サービス アカウントは ID であるため、他のメンバーと同様に、ロールを付与することでプロジェクト内のリソースにアクセスできます。たとえば、アプリケーションのサービス アカウントに Cloud Storage バケット内のオブジェクトへのアクセスを許可する場合は、サービス アカウントにバケットに対するストレージ オブジェクト閲覧者のロール(roles/storage.objectViewer)を付与できます。

ただし、サービス アカウントは、IAM ポリシーを受け入れるリソースでもあります。つまり、サービス アカウントまたはサービス アカウントの親リソースの 1 つに対するロールを他のメンバーに付与することで、そのメンバーがサービス アカウントにアクセスできるようになります。たとえば、ユーザーにサービス アカウントの権限の借用を許可するには、そのサービス アカウントに対するサービス アカウントのユーザーロール(roles/iam.serviceAccountUser)を付与します。

サービス アカウントを含め、メンバーにロールを付与する方法の詳細については、アクセス権の付与、変更、取り消しをご覧ください。

サービス アカウントにロールを付与する方法の詳細については、サービス アカウントの権限借用の管理をご覧ください。

サービス アカウントのユーザーロール

サービス アカウント ユーザーロール(roles/iam.serviceAccountUser)は、プロジェクト内のすべてのサービス アカウントのプロジェクト レベルまたはサービス アカウント レベルで指定できます。

  • プロジェクトでユーザーにサービス アカウント ユーザーロールを付与すると、将来作成されるサービス アカウントを含む、プロジェクトにおけるすべてのサービス アカウントへのアクセス権がユーザーに付与されます。

  • 特定のサービス アカウントでユーザーにサービス アカウント ユーザーのロールを付与した場合、ユーザーにはそのサービス アカウントのみへのアクセス権が付与されます。

サービス アカウントでサービス アカウント ユーザーのロールを付与されたユーザーは、それを使用して、サービス アカウントがアクセスできるすべてのリソースに間接的にアクセスできます。たとえば、サービス アカウントに Compute Admin のロール(roles/compute.admin)が付与されている場合、そのサービス アカウントでサービス アカウント ユーザーのロール(roles/iam.serviceAccountUser)が付与されているユーザーは、Compute Engine インスタンスを起動するサービス アカウントの役目を果たせます。この場合、ユーザーはサービス アカウントの権限を借用し、サービス アカウントに付与されたロールと権限を使ってタスクを実行します。

サービス アカウントに対するユーザーロールの付与については、サービス アカウントの権限借用の管理をご覧ください。

サービス アカウントは、サービスレベルのセキュリティを表します。サービスのセキュリティは、サービス アカウントを管理 / 使用できる IAM ロールを持つユーザーと、これらのサービス アカウントの非公開外部キーを保持するユーザーによって決まります。セキュリティを確保するためのベスト プラクティスは次のとおりです。

  • IAM API を使用してサービス アカウント、キー、およびサービス アカウントのポリシーを監査します。
  • サービス アカウントに外部キーが不要な場合は、削除します。
  • ユーザーがサービス アカウントを管理または使用する権限を必要としない場合は、該当する IAM ポリシーから削除します。
  • サービス アカウントには最小限の権限を設定してください。デフォルトのサービス アカウントにはプロジェクト編集者(roles/editor)ロールが自動的に付与されます。このアカウントは慎重に使用してください。

ベスト プラクティスの詳細については、サービス アカウントについてをご覧ください。

サービス アカウント トークン作成者のロール

このロールはサービス アカウントの権限を借用でき、OAath2 アクセス トークンの作成、blob の署名、JWT の署名を行うことができます。

アクセス スコープ

アクセス スコープは、Compute Engine 仮想マシン(VM)インスタンスの権限を指定するレガシーな方法です。gcloud ツールおよびクライアント ライブラリからのリクエストで使用されるデフォルトの OAuth スコープを定義します。

Google Cloud は、アクセス スコープではなく IAM を使用して Compute Engine インスタンスの権限を指定するようになりました。ただし、サービス アカウントの権限を借用するようにインスタンスを構成する場合は、引き続きアクセス スコープを設定する必要があります。

詳細については、Compute Engine のドキュメントをご覧ください。

有効期間が短いサービス アカウント認証情報

Google Cloud サービス アカウントの ID を使用できる有効期間が短い認証情報を作成できます。これらの認証情報は、Google Cloud APIs やその他の Google 以外の API への呼び出しを認証するために使用できます。

これらの認証情報の最も一般的な使用例は、異なるプロジェクト、組織、アカウント間で Google Cloud リソースへのアクセスを一時的に委任する場合です。たとえば、外部の呼び出し元に高度な権限のサービス アカウントの恒久的な認証情報を提供する代わりに、一時的な緊急アクセスを許可できます。あるいは、高度な権限のサービス アカウントの認証情報を必要としない外部の呼び出し元に対しては、より権限が少ない特定のサービス アカウントの権限借用を許可することもできます。

詳細については、有効期間が短いサービス アカウント認証情報の作成をご覧ください。

Workload Identity 連携

Amazon Web Services(AWS)や Microsoft Azure など、Google Cloud の外部で実行されるワークロードの ID に、サービス アカウントになりすますことができる権利を付与できます。これにより、サービス アカウント キーを使用する代わりに、有効期間が短い認証情報を使用してリソースに直接アクセスできます。

詳細については、Workload Identity 連携をご覧ください。

アプリケーションのデフォルト認証情報

アプリケーションのデフォルト認証情報は、Google Cloud クライアント ライブラリがサービス アカウントの認証情報を自動的に検出するために使用するツールです。環境変数にサービス アカウント キーを指定すると、アプリケーションのデフォルト認証情報が自動的にそのサービス アカウント キーを使用します。キーを指定しない場合、アプリケーションのデフォルト認証情報は、コードを実行しているリソースに接続されたサービス アカウント、またはコードを実行しているサービスのデフォルト サービス アカウントを使用します。

詳細については、認証情報を自動的に見つけるをご覧ください。

次のステップ

サービス アカウントの使用に関するベスト プラクティスについては、サービス アカウントについてをご覧ください。

以下のガイドを参照して、それぞれの手順を理解します。