Workload Identity


Workload Identity は、Google Kubernetes Engine(GKE)で実行されるワークロードで、安全で管理しやすい方法で Google Cloud サービスにアクセスする場合におすすめの方法です。

GKE で Workload Identity を有効にして使用する方法については、Workload Identity の使用をご覧ください。

フリート Workload Identity を使用すると、Anthos クラスタを含むフリートに登録されているクラスタに Workload Identity 連携のサポートを提供できます。

用語

このドキュメントでは、Kubernetes サービス アカウントIdentity and Access Management(IAM)サービス アカウントを区別しています。

Kubernetes サービス アカウント
GKE Pod で実行されているプロセスの ID を提供する Kubernetes リソース。
IAM サービス アカウント
アプリケーションから Google Cloud APIs への承認済み呼び出しを可能にする Google Cloud リソース。

Workload Identity とは

GKE で実行されるアプリケーションで、Compute Engine API、BigQuery Storage API、Machine Learning API などの Google Cloud APIs へのアクセスが必要になる場合があります。

Workload Identity を使用すると、GKE クラスタ内の Kubernetes サービス アカウントが IAM サービス アカウントとして機能します。構成された Kubernetes サービス アカウントを使用する Pod は、Google Cloud APIs にアクセスするときに IAM サービス アカウントとして自動的に認証されます。Workload Identity を使用すると、クラスタ内のアプリケーションごとにきめ細かい ID と認可を割り当てることができます。

Workload Identity の仕組み

クラスタで Workload Identity を有効にすると、GKE はクラスタの Google Cloud プロジェクトに固定の Workload Identity プールを自動的に作成します。Workload Identity プールを使用すると、IAM で Kubernetes サービス アカウントの認証情報を理解し、信頼できます。Workload Identity プールの形式は次のとおりです。

PROJECT_ID.svc.id.goog

GKE は、Workload Identity を使用するプロジェクト内のすべてのクラスタでこのプールを使用します。

Workload Identity を使用するように Namespace で Kubernetes サービス アカウントを構成すると、IAM は次のメンバー名を使用して認証情報を認証します。

serviceAccount:PROJECT_ID.svc.id.goog[KUBERNETES_NAMESPACE/KUBERNETES_SERVICE_ACCOUNT]

このメンバー名で:

  • PROJECT_ID: Google Cloud プロジェクト ID。
  • KUBERNETES_NAMESPACE: Kubernetes サービス アカウントの名前空間。
  • KUBERNETES_SERVICE_ACCOUNT: リクエストを行っている Kubernetes サービス アカウントの名前です。

Workload Identity を構成するプロセスには、IAM ポリシー バインディングを使用して、Kubernetes サービス アカウント メンバー名を、ワークロードに必要な権限を持つ IAM サービス アカウントにバインドする作業があります。この Kubernetes サービス アカウントを使用するワークロードからの Google Cloud API 呼び出しは、バインドされた IAM サービス アカウントとして認証されます。

ID の同一性

IAM が Workload Identity で Kubernetes サービス アカウントの確認に使用するメンバー名は、次の変数を使用します。

  • Kubernetes サービス アカウント名。
  • Kubernetes サービス アカウントの名前空間。
  • Google Cloud プロジェクト ID。

プロジェクトに Kubernetes サービス アカウント用の同じ名前と名前空間を持つ複数のクラスタがある場合、すべてのアカウントが同じメンバー名に解決されます。この共通 ID を使用すると、個々のクラスタではなく Workload Identity プールに Google Cloud リソースへのアクセス権を付与できます。

たとえば、次の図について考えてみます。クラスタ A、B、C は同じ Google Cloud プロジェクトに属しており、同じ Workload Identity プールに属します。クラスタ A とクラスタ B の両方の backend 名前空間内のアプリケーションは、Google Cloud リソースへのアクセス時に back IAM サービス アカウントとして認証されます。IAM は、呼び出しを行うクラスタを区別しません。

Workload Identity プール内の ID の同一性を示す図
Workload Identity を使用して Google Cloud APIs にアクセスする際の ID の同一性

この ID の同一性は、特定の Workload Identity プール内のすべてのクラスタを信頼できなければならないことも意味します。 たとえば、前の例のクラスタ C が信頼できないチームによって所有されていた場合、backend 名前空間を作成し、back IAM サービス アカウントを使用して Google Cloud APIs にアクセスできます。クラスタ A やクラスタ B とまったく同じです

信頼できないアクセスを回避するには、クラスタを別々のプロジェクトに配置して、異なる Workload Identity プールを取得するか、共通のメンバー名を回避するために名前空間名が互いに異なるようにします。

GKE メタデータ サーバーについて

Workload Identity が有効になっている GKE のノードはすべて、GKE メタデータ サーバーにメタデータを保存します。GKE メタデータ サーバーは、Kubernetes ワークロードに必要な Compute Engine メタデータ サーバー エンドポイントのサブセットです。

GKE メタデータ サーバーは DaemonSet として実行され、Linux ノードごとに 1 つの Pod を使用するか、クラスタ内のすべての Windows ノードにネイティブ Windows サービスを実行します。メタデータ サーバーは、http://metadata.google.internal169.254.169.254:80)への HTTP リクエストをインターセプトします。たとえば、GET /computeMetadata/v1/instance/service-accounts/default/token リクエストは、Pod がなりすましを行うように構成された IAM サービス アカウントのトークンを取得します。GKE メタデータ サーバーへのトラフィックは、Pod をホストする VM インスタンスから離れることはありません。

次の表に、GKE メタデータ サーバーで利用可能な Compute Engine メタデータ サーバー エンドポイントのサブセットを示します。Compute Engine メタデータ サーバーで利用可能なエンドポイントの一覧については、デフォルトの VM メタデータ値をご覧ください。

インスタンス メタデータ

インスタンス メタデータは、次のディレクトリに保存されます。Compute Engine インスタンス メタデータ エントリの完全なリストについては、VM インスタンス メタデータをご覧ください。

http://metadata.google.internal/computeMetadata/v1/instance/

エントリ 説明
hostname

ノードのホスト名。

id

ノードの一意の ID。

service-accounts/

ノードに関連付けられているサービス アカウントのディレクトリ。各サービス アカウントごとに、次の情報を利用できます。

  • aliases
  • email: サービス アカウントのメールアドレス。
  • identity: ノードに固有の JSON ウェブトークン(JWT)。リクエストには audience パラメータを含める必要があります。例: ?audience=http://www.example.com
  • scopes: サービス アカウントに割り当てられているアクセス スコープ。
  • token: ワークロードを認証するための OAuth 2.0 アクセス トークン。

インスタンス属性

インスタンス メタデータは、次のディレクトリに保存されます。Compute Engine インスタンス属性エントリの完全なリストについては、インスタンス属性をご覧ください。

http://metadata.google.internal/computeMetadata/v1/instance/attributes/

エントリ 説明
cluster-location

クラスタの Compute Engine のゾーンまたはリージョン。

cluster-name

GKE クラスタの名前。

cluster-uid

GKE クラスタの UID。

プロジェクトのメタデータ

クラスタ プロジェクト メタデータは、次のディレクトリに保存されます。Compute Engine プロジェクト メタデータのエントリの完全なリストについては、プロジェクト メタデータをご覧ください。

http://metadata.google.internal/computeMetadata/v1/project/

エントリ 説明
project-id

Google Cloud プロジェクト ID。

numeric-project-id

Google Cloud プロジェクト番号。

Workload Identity に代わる方法

Workload Identity に代わる次のいずれかの方法を使用して、GKE から Google Cloud APIs にアクセスできます。

  • サービス アカウント キーをエクスポートして Kubernetes Secret として保存します。Google サービス アカウント キーには有効期限がないため、手動でローテーションする必要があります。サービス アカウント キーをエクスポートすると、セキュリティ侵害を受けた場合、それが検出されなければ侵害の範囲が拡大する可能性があります。エクスポートされたキーが盗まれた場合、攻撃者は、キーを認識して手動で取り消すまで、そのサービス アカウントとして認証に使用できます。

  • ノードの Compute Engine のデフォルト サービス アカウントを使用します。プロジェクト内の任意の IAM サービス アカウントとしてノードプールを実行できます。ノードプールの作成時にサービス アカウントを指定しなければ、GKE はプロジェクトの Compute Engine のデフォルトのサービス アカウントを使用します。デフォルトの Compute Engine サービス アカウントは、そのノードにデプロイされているすべてのワークロードで共有されます。これにより、権限が過剰にプロビジョニングされることがあります。これは、最小権限の原則に反し、マルチテナント クラスタには適していません。

次のステップ