サービス アカウント

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

始める前に

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

サービス アカウントとは

サービス アカウントは、ユーザーではなく、アプリケーションや仮想マシン(VM)インスタンスで使用される特別なアカウントです。アプリケーションは、サービス アカウントを使用して、承認された API 呼び出しを行います。

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

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

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

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

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

サービス アカウント キー

各サービス アカウントは、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 組織ポリシーの制約をプロジェクト、フォルダ、組織全体に適用して、使用を制限できます。制約を適用した後、適切に管理された場所でユーザーが管理するキーを有効にして、キーが管理されていないことによる潜在的なリスクを最小限に抑えることができます。

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

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

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

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

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

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

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

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

デフォルトのサービス アカウントは、Google Cloud サービスを使い始めるのに役立ちます。本番環境ワークロードでは、お客様独自のユーザー管理サービス アカウントを作成し、各サービス アカウントに適切なロールを付与することを強くおすすめします。

デフォルトのサービス アカウントが作成されると、プロジェクト編集者のロール(roles/editor)がそれに自動的に付与されます。このロールにはかなり多数の権限が含まれています。最小権限の原則に従い、自動的なロール付与を無効にすることを強くおすすめします。そうするには、組織ポリシーに制約を追加するか、編集者のロールを手動で取り消します。ロールの付与を無効化または取り消す場合は、どのロールをデフォルト サービス アカウントに付与するかを決定する必要があります。

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

サービス サービス アカウント名 メールアドレス
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 管理サービス アカウント

ユーザー管理のサービス アカウントとデフォルトのサービス アカウントに加えて、プロジェクトの IAM ポリシーや Cloud Console に他のサービス アカウントも表示される場合があります。これらのサービス アカウントは Google によって作成、管理され、Google サービスで使用されます。

Google が管理する各サービス アカウントの表示名は、「サービス エージェント」または「サービス アカウント」で終わります。一部のサービス アカウントは表示されていますが、一部は非表示になっています。

たとえば、プロジェクトに Google API サービス エージェントという名前のサービス アカウントがあり、project-number@cloudservices.gserviceaccount.com という形式のメールアドレスが設定されているとします。

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

同様に、プロジェクトの他の Google 管理サービス アカウントにもロールが自動的に付与されます。通常、これらのロールの名前は serviceAgent で終わります。これらのロールの変更や取り消しは行わないでください。

次の表に、プロジェクトに存在する可能性がある他の Google 管理サービス アカウントを示します。各サービス アカウントのメールアドレスも示します。project-number は、プロジェクト番号で置き換えてください。プロジェクト番号は、プロジェクトの Cloud Console ダッシュボードで確認できます。

Google 管理サービス アカウント
AI Platform サービス エージェント service-project-number@gcp-sa-aiplatform.iam.gserviceaccount.com
Cloud AI Platform Notebooks サービス アカウント service-project-number@gcp-sa-notebooks.iam.gserviceaccount.com
Cloud Composer サービス エージェント service-project-number@cloudcomposer-accounts.iam.gserviceaccount.com
Cloud Data Fusion サービス アカウント service-project-number@gcp-sa-datafusion.iam.gserviceaccount.com
Cloud Dataflow サービス アカウント service-project-number@dataflow-service-producer-prod.iam.gserviceaccount.com
Cloud Life Sciences サービス エージェント service-project-number@gcp-sa-lifesciences.iam.gserviceaccount.com
Cloud Pub/Sub サービス アカウント service-project-number@gcp-sa-pubsub.iam.gserviceaccount.com
Cloud Scheduler サービス アカウント service-project-number@gcp-sa-cloudscheduler.iam.gserviceaccount.com
Cloud Source Repositories サービス エージェント service-project-number@sourcerepo-service-accounts.iam.gserviceaccount.com
Compute Engine サービス エージェント service-project-number@compute-system.iam.gserviceaccount.com
Google Cloud Dataproc サービス エージェント service-project-number@dataproc-accounts.iam.gserviceaccount.com
Google Cloud Functions サービス エージェント service-project-number@gcf-admin-robot.iam.gserviceaccount.com
Google Cloud ML Engine サービス エージェント service-project-number@cloud-ml.google.com.iam.gserviceaccount.com
Google Cloud Run サービス エージェント service-project-number@serverless-robot-prod.iam.gserviceaccount.com
Kubernetes Engine サービス エージェント service-project-number@container-engine-robot.iam.gserviceaccount.com
TPU サービス エージェント service-project-number@cloud-tpu.iam.gserviceaccount.com

サービス アカウント権限

サービス アカウントは ID であることに加えて、IAM ポリシーが付加されたリソースでもあります。これらのポリシーは、サービス アカウントを使用できるユーザーを決定します。

たとえば、ユーザー A はサービス アカウント上で編集者のロールを持ち、ユーザー B はサービス アカウント上に閲覧者のロールを持つことができます。これは他の Google Cloud リソースにロールを付与するのとまったく同じです。

デフォルトの Compute Engine および App Engine サービス アカウントには、作成時にプロジェクトの編集者のロールが付与されます。これにより、アプリまたは VM インスタンスで実行されるコードは必要な権限を持ちます。この場合、サービス アカウントは ID となり、リソース(プロジェクト)に関する編集者のロールが付与されます。

アプリケーションに Cloud Storage バケットへのアクセスを許可する場合は、そのアプリケーションが使用するサービス アカウントに Cloud Storage バケットの読み取り権限を付与します。この場合、サービス アカウントは、別のリソース(Cloud Storage バケット)に対する権限を付与する対象の ID です。

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

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

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

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

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

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

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

  • IAM API を使用してサービス アカウント、キー、およびサービス アカウントのポリシーを監査します。
  • サービス アカウントに外部キーが不要な場合は、削除します。
  • ユーザーがサービス アカウントを管理または使用する権限を必要としない場合は、該当する IAM ポリシーから削除します。

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

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

このロールはサービス アカウントの代理として機能することができ、OAath2 アクセス トークンの作成、blob の署名、JWT の署名を行うことができます。

サービス アカウント アクターのロール

このロールは非推奨になりました。サービス アカウントとして操作を実行する必要がある場合は、サービス アカウント ユーザーロールを使用します。さらに、実質的にサービス アカウント アクターと同じ権限を付与するには、サービス アカウント トークン作成者も付与する必要があります。

アクセス スコープ

アクセス スコープは、VM の権限を指定するレガシーな方法です。IAM のロールが存在する前は、アクセス スコープは、サービス アカウントに権限を付与する唯一のメカニズムでした。現在では権限付与の主要な方法でなくなりましたが、インスタンスをサービス アカウントとして実行するように構成する場合は、アクセス スコープを設定する必要があります。アクセス スコープについて詳しくは、Google Compute Engine のドキュメントをご覧ください。

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

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

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

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

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

アプリケーションのデフォルト認証情報は、Google Cloud の内部および外部で、また複数の Google Cloud プロジェクト間で操作を実行する際に、サービス アカウントを簡単に使用できるようにするためのメカニズムです。最も一般的な使用例としては、ローカルマシン上のコードをテストしてから Google Cloud の開発プロジェクトに移動し、その後、Google Cloud の本番環境プロジェクトに移動するなどが考えられます。アプリケーションのデフォルトの認証情報を使用すると、サービス アカウントがシームレスに動作するようになります。ローカルマシンでテストを行う場合、ローカルに保存されているサービス アカウント キーを使用しますが、Compute Engine で実行される場合は、プロジェクトのデフォルトの Compute Engine サービス アカウントを使用します。詳細については、アプリケーションのデフォルト認証情報をご覧ください。

次のステップ

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

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