GKE でのサービス アカウントについて

このページでは、アプリケーションの ID を提供する Google Kubernetes Engine（GKE）のサービス アカウントについて説明します。

サービス アカウントは、ユーザーではなくアプリケーションが使用する ID です。GKE では、Kubernetes サービス アカウントと Identity and Access Management サービス アカウントを操作します。

Kubernetes サービス アカウントと IAM サービス アカウント

次の表に、Kubernetes サービス アカウントと IAM サービス アカウントの主な違いを示します。

GKE のサービス アカウントの種類
Kubernetes ServiceAccount
  • Kubernetes API サーバーの ServiceAccount オブジェクト
  • クラスタ内の Kubernetes Namespace にスコープ設定
  • クラスタ内で Pod が使用する ID を提供する
IAM サービス アカウント
  • IAM API を使用して管理する
  • Google Cloud プロジェクトにスコープ設定されている
  • プロジェクト内のアプリケーションに ID を提供する

Kubernetes ServiceAccount

Kubernetes サービス アカウントはクラスタレベルで管理され、Kubernetes API サーバーに ServiceAccount オブジェクトとして存在します。Kubernetes のドキュメントと GKE のドキュメントでは、これらの Kubernetes リソースを IAM などの他の環境のサービス アカウントと区別するために ServiceAccount という用語がよく使用されます。

Namespace に Kubernetes ServiceAccount を作成し、Pod マニフェストの serviceAccountName フィールドを使用して、その ServiceAccount を Pod に割り当てます。ノードの kubelet プロセスは、割り当てられた ServiceAccount の有効期間の短い署名なしトークンを取得し、そのトークンを予測ボリュームとして Pod にマウントします。

有効期間の短い署名なしトークンは、OpenID Connect（OIDC）プロバイダである API サーバーによって署名された JSON ウェブトークン（JWT）です。署名なしトークンを検証するには、GKE API で projects.locations.clusters.getJwks メソッドを呼び出して、クラスタの公開検証鍵を取得します。

Kubernetes ServiceAccount の認証情報のローテーション

Kubernetes ServiceAccount の認証情報が不正使用された場合は、次のいずれかの方法で認証情報を取り消します。

  • Pod を再作成する: 署名なしトークンは一意の Pod UID ごとにバインドされるため、Pod を再作成すると以前の認証情報が無効になります。
  • Kubernetes ServiceAccount を再作成する: 署名なしトークンは、Kubernetes API の ServiceAccount オブジェクトの UID にバインドされます。ServiceAccount を削除し、同じ名前の新しい ServiceAccount を作成します。新しい ServiceAccount の UID が異なるため、以前のトークンは無効になります。
  • 認証情報のローテーションを行う: これにより、クラスタ内のすべての Kubernetes ServiceAccount 認証情報が取り消されます。ローテーションによって、クラスタの CA 証明書と IP アドレスも変更されます。詳細については、認証情報のローテーションをご覧ください。

IAM サービス アカウント

IAM サービス アカウントは、IAM API を使用してプロジェクト レベルで管理されます。これらのサービス アカウントを使用して、プログラムでの Google Cloud APIs の呼び出しや、Google Cloud プロダクトで実行されているアプリケーションの権限の管理などの操作を実行できます。

詳細については、IAM サービス アカウントの概要をご覧ください。

GKE サービス エージェント

IAM サービス エージェントは、Google Cloud が管理する IAM サービス アカウントです。

GKE は Kubernetes Engine サービス エージェントを使用して、ノード、ディスク、ロードバランサなどのクラスタ リソースのライフサイクルを管理します。このサービス エージェントにはドメイン container-engine-robot.iam.gserviceaccount.com があり、GKE API を有効にするとプロジェクトの Kubernetes Engine サービス エージェントのロール（roles/container.serviceAgent）が付与されます。

このサービス エージェントの ID は次のとおりです。

service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com

PROJECT_NUMBER は、プロジェクト番号（数字）です。

GKE サービス エージェントを無効にする場合は、サービス アカウントの有効化の手順に沿ってこのエージェントを復元できます。

プロジェクト内のサービス エージェントの権限を削除した場合は、エラー 400/403: アカウントに対する編集権限がありませんの手順に沿って権限を復元できます。

GKE サービス エージェントを削除する場合は、サービス アカウントの削除の取り消しの手順に沿ってこのエージェントの削除を取り消すことができます。

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

デフォルトでは、GKE ノードは Compute Engine のデフォルトのサービス アカウントを使用します。デフォルトでは、このサービス アカウントには編集者ロール（roles/editor）が付与され、GKE ノードに必要な権限よりも多くの権限が付与されています。クラスタでノードを実行するために必要な最小権限を使用するロールの使用を検討してください。

ユーザー管理サービス アカウントに移行する場合を除き、デフォルトの Compute Engine サービス アカウントを無効にしないでください。

最小権限

GKE では、クラスタを操作するために最小限の IAM 権限が必要です。最小権限の IAM サービス アカウントを作成する手順については、最小権限の Google サービス アカウントの使用をご覧ください。

特定のサービス アカウントを使用する場合

使用するサービス アカウントのタイプは、アプリケーションに提供する ID のタイプによって以下のように異なります。

  • クラスタで使用する Pod の ID を提供する: Kubernetes ServiceAccount を使用します。すべての Kubernetes Namespace には default ServiceAccount がありますが、各 Namespace の各ワークロードに最小限権限の新しい ServiceAccount を作成することをおすすめします。
  • クラスタ外で使用する Pod の ID を提供する: GKE 用 Workload Identity 連携を使用します。GKE 用 Workload Identity 連携を使用すると、IAM ポリシーのプリンシパルとして ServiceAccount などの Kubernetes リソースを指定できます。たとえば、Pod から Secret Manager や Spanner などの Google Cloud API を呼び出す場合に、GKE 用 Workload Identity 連携を使用します。
  • ノードにデフォルトの ID を指定する: GKE クラスタまたはノードを作成するときに、カスタムの最小権限 IAM サービス アカウントを使用します。カスタムの IAM サービス アカウントを使用しない場合、GKE は Compute Engine のデフォルト サービス アカウントを使用します。このアカウントには、プロジェクト内で広範な権限があります。

次のステップ