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 は、プロジェクト番号(数字)です。

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

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

GKE は、ノードに接続されている IAM サービス アカウントを使用して、ロギングやモニタリングなどのシステムタスクを実行します。少なくとも、これらのノード サービス アカウントには、プロジェクトに対する Kubernetes Engine デフォルト ノード サービス アカウントroles/container.defaultNodeServiceAccount)ロールが必要です。デフォルトでは、GKE はプロジェクトで自動的に作成される Compute Engine のデフォルトのサービス アカウントをノード サービス アカウントとして使用します。

組織で iam.automaticIamGrantsForDefaultServiceAccounts 組織のポリシー制約が適用されている場合、プロジェクトのデフォルトの Compute Engine サービス アカウントに GKE に必要な権限が自動的に付与されないことがあります。

プロジェクトまたは組織内の他の機能に Compute Engine のデフォルトのサービス アカウントを使用すると、サービス アカウントに GKE が必要とする以上の権限が付与され、セキュリティ リスクにさらされる可能性があります。

Compute Engine のデフォルト サービス アカウントに roles/container.defaultNodeServiceAccount ロールを付与する手順は次のとおりです。

console

  1. [ようこそ] ページに移動します。

    [ようこそ] に移動

  2. [プロジェクト番号] フィールドで、 [クリップボードにコピー] をクリックします。
  3. [IAM] ページに移動します。

    [IAM] に移動

  4. [ アクセスを許可] をクリックします。
  5. [新しいプリンシパル] フィールドに次の値を指定します。
    PROJECT_NUMBER-compute@developer.gserviceaccount.com
    PROJECT_NUMBER は、コピーしたプロジェクト番号に置き換えます。
  6. [ロールを選択] メニューで、[Kubernetes Engine のデフォルト ノード サービス アカウント] ロールを選択します。
  7. [保存] をクリックします。

gcloud

  1. Google Cloud プロジェクト番号を確認します。
    gcloud projects describe PROJECT_ID \
        --format="value(projectNumber)"

    PROJECT_ID を実際のプロジェクト ID に置き換えます。

    出力は次のようになります。

    12345678901
    
  2. Compute Engine のデフォルト サービス アカウントに roles/container.defaultNodeServiceAccount ロールを付与します。
    gcloud projects add-iam-policy-binding PROJECT_ID \
        --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com" \
        --role="roles/container.defaultNodeServiceAccount"

    PROJECT_NUMBER は、前の手順で取得したプロジェクト番号に置き換えます。

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

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

使用するサービス アカウントのタイプは、アプリケーションに提供する 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 のデフォルト サービス アカウントを使用します。

次のステップ