サービス アカウント

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

始める前に

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

サービス アカウントとは

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

たとえば、サービス アカウントを Compute Engine VM に接続し、その VM で実行されるアプリケーションをサービス アカウントとして認証できます。また、サービス アカウントには、リソースへのアクセスを許可する IAM ロールを付与できます。サービス アカウントはアプリケーションの ID として使用されます。サービス アカウントのロールは、アプリケーションがどのリソースにアクセスできるかを制御します。

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

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

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

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

サービス アカウントの作成の防止

組織、プロジェクト、またはフォルダで constraints/iam.disableServiceAccountCreation 組織ポリシー制約を適用することで、サービス アカウントの作成を防止できます。

この制約を適用する前に、次の制限事項について検討してください。

サービス アカウントと Google グループ

Google グループにサービス アカウントを追加して、グループにロールを付与できます。ただし、サービス アカウントをグループに追加することはおすすめしません。サービス アカウントはアプリケーションによって使用され、各アプリケーションが独自のアクセス要件を持つ可能性があります。

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

各サービス アカウントは、公開 / 秘密 RSA 鍵ペアに関連付けられています。Service Account Credentials API は、この内部鍵ペアを使用して有効期間が短いサービス アカウント認証情報を作成し、blob と JSON ウェブトークン(JWT)に署名します。この鍵ペアは Google が管理する鍵ペアと呼ばれます。

また、複数の 公開 / 秘密 RSA 鍵ペア(ユーザーが管理する鍵ペア)を作成し、秘密鍵を使用して Google API で認証することもできます。この秘密鍵はサービス アカウント キーと呼ばれています。

Google が管理する鍵ペア

Google が管理する鍵ペアは、Service Account Credentials API や、Google Cloud サービス(App Engine や Compute Engine など)によって使用され、有効期間が短いサービス アカウント認証情報を生成します。

Google が管理する鍵ペアは自動的にローテーションされ、最長 2 週間署名のために使用されます。ローテーション プロセスは確率論的です。新しい鍵の使用期間は鍵の存続期間に応じて多少増減します。

Google が管理する鍵ペアの秘密鍵は常にエスクローに保管され、直接アクセスすることはできません。

Google が管理する鍵ペアの公開鍵は一般公開されているため、秘密鍵を使用して作成された署名は誰でも確認できます。公開鍵には、さまざまな形式でアクセスできます。

  • X.509 証明書: https://www.googleapis.com/service_accounts/v1/metadata/x509/SERVICE_ACCOUNT_EMAIL
  • JSON Web Key(JWK): https://www.googleapis.com/service_accounts/v1/jwk/SERVICE_ACCOUNT_EMAIL
  • RAW 形式: https://www.googleapis.com/service_accounts/v1/metadata/raw/SERVICE_ACCOUNT_EMAIL

公開鍵をダウンロードしてキャッシュに保存する場合は、常に現在の鍵を保持できるように最長 24 時間キャッシュに保存することをおすすめします。公開鍵を取得するタイミングに関係なく、取得した公開鍵は少なくとも 24 時間有効です。

ユーザーが管理する鍵ペア

サービス アカウントのユーザー管理鍵ペアを作成し、各鍵ペアの秘密鍵を使用して Google API で認証できます。この秘密鍵はサービス アカウント キーと呼ばれています。各サービス アカウントには、最大 10 個のサービス アカウント キーを設定できます。Google では、ユーザーが管理する鍵ペアの公開部分のみを格納します。

サービス アカウントでユーザーが管理する鍵ペアを作成するには、いくつかの方法があります。

ユーザーが管理する鍵は非常に強力な認証情報であり、正しく管理しなければセキュリティ上のリスクとなります。ユーザーが管理する鍵の使用を制限するには、次の組織ポリシー制約を組織、プロジェクト、またはフォルダに適用します。

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

Workload Identity 連携を使用するために、これらの制約を適用する場合は、Workload Identity 連携に関する組織ポリシー制約を使用して許可する ID プロバイダを指定することを検討してください。

ユーザーが管理する鍵の有効期限の指定

デフォルトでは、ユーザー管理のサービス アカウント キーを作成するときに、鍵の有効期限は設定されません。このデフォルトを変更するには、プロジェクト、フォルダまたは組織で新たに作成したすべての鍵に有効期限を設定します。

有効期限は、システムに一時的にアクセスする必要がある場合に使用します。特に、システムにサービス アカウント キーが必要な場合などに使用します。たとえば、次のシナリオでは有効期限を設定します。

  • デベロッパーが、サービス アカウント キーを必要とする Codelab を完了する必要がある。
  • デベロッパーが、サービス アカウント キーが必要な CLI ツールを実行する必要がある。
  • インターンや請負業者などの臨時従業員が、新しいアプリケーションの概念実証を作成する。

以下のシナリオでは、有効期限を使用しないようにします。

  • 本番環境ワークロード。本番環境では、サービス アカウント キーが期限切れになると、誤ってサービスが停止する可能性があります。代わりに有効期限のない鍵を使用し、鍵のローテーションでライフサイクルを管理します。
  • 継続的インテグレーション(CI)パイプラインなど、永続的にアクセスする必要がある非本番環境ワークロード。

有効期限を設定するには、リソースの設定を使用して settings/iam-serviceAccountKeyExpiry の設定を更新します。この設定をプロジェクト、フォルダまたは組織で更新すると、その親リソース内で新しく作成されたすべてのサービス アカウント キーに有効期限が適用されます。既存の鍵は影響を受けません。

この設定の詳細については、リソース設定のインデックスをご覧ください。設定の更新方法については、ローカル設定値の変更をご覧ください。

8hours24hours7days などの有効期限は短くすることをおすすめします。有効期限を短くすることで、チームが鍵の更新プロセスを十分にテストできるようになります。まず、最も短い有効期限を設定し、その後、必要に応じて有効期限を長くしていきます。

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

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

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

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

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

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 ページに、Google マネージド サービス アカウントが表示されることがあります。

コンソールの [サービス アカウント] ページには、Google マネージド サービス アカウントは表示されません。

例:

  • Google API サービス エージェントプロジェクトの許可ポリシーは、Google API サービス エージェントという名前のサービス アカウントを参照する可能性があります。このメールアドレスは project-number@cloudservices.gserviceaccount.com という形式になります。

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

  • その他のサービス エージェント。プロジェクトの許可ポリシーは、個々のサービスに代わって動作する他の Google マネージド サービス アカウントを参照する場合があります。これらのサービス アカウントは、サービス エージェントと呼ばれます。これらのサービス エージェントにロールが自動的に付与される場合があります。通常、これらのロール名の最後には serviceAgent が付いています。

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

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

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

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

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

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

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

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

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

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

    このアプローチでは、組織のすべてのサービス アカウントを少数のプロジェクトに分けて割り当てるため、サービス アカウントを管理しやすくします。ただし、他のプロジェクト内のリソースにサービス アカウントを接続して、プロジェクトが異なるこれらのリソースでサービス アカウントを ID として使用できようにする場合、追加の設定作業が必要になります。

    あるプロジェクト内にあるサービス アカウントが別のプロジェクトのリソースにアクセスする場合、通常は両方のプロジェクトでそのリソースの API を有効にする必要があります。たとえば、サービス アカウントがプロジェクト my-service-accounts 内にあり、Cloud SQL インスタンスがプロジェクト my-application 内にある場合、my-service-accountsmy-application の両方で Cloud SQL API を有効にする必要があります。

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

サービス アカウント権限

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

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

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

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

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

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

サービス アカウント ユーザーロール(roles/iam.serviceAccountUser)は、プロジェクト内のすべてのサービス アカウントに対してプロジェクト単位で指定することも、サービス アカウント単位で指定することもできます。

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

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

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

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

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

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

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

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

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

アクセス スコープ

アクセス スコープは、Compute Engine 仮想マシン(VM)インスタンスの権限を指定するレガシーな方法です。gcloud CLI およびクライアント ライブラリからのリクエストで使用されるデフォルトの 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 クライアント ライブラリがサービス アカウントの認証情報を自動的に検出するために使用するツールです。環境変数にサービス アカウント キーを指定すると、アプリケーションのデフォルト認証情報が自動的にそのサービス アカウント キーを使用します。キーを指定しない場合、アプリケーションのデフォルト認証情報は、コードを実行しているリソースに接続されたサービス アカウント、またはコードを実行しているサービスのデフォルト サービス アカウントを使用します。

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

次のステップ

使ってみる

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

無料で開始