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 プールが自動的に作成されます。

PROJECT_ID.svc.id.goog

Workload Identity プールには、IAM が Kubernetes サービス アカウントの認証情報を把握して信頼できるようにする命名形式が用意されています。Workload Identity を有効にしても、デフォルトではワークロードに IAM 権限は付与されません。

名前空間で Kubernetes サービス アカウントを構成して Workload Identity を使用する場合、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 ポリシー バインディングを使用して、ワークロードに必要な権限のある IAM サービス アカウントに Kubernetes サービス アカウント名をバインドします。この Kubernetes サービス アカウントを使用するワークロードからの Google Cloud APIs の呼び出しは、バインドされた 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 が信頼できないチームによって所有されていた場合、クラスタ A とクラスタ B と同様に、backend 名前空間を作成し、back IAM サービス アカウントを使用して Google Cloud APIs にアクセスできます。

信頼できないアクセスを回避するには、クラスタを別々のプロジェクトに配置し、別々の 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 メタデータ値をご覧ください。

インスタンス メタデータ

インスタンス メタデータは、次のディレクトリに保存されます。

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 アクセス トークン。
zone

GKE ノードの Compute Engine ゾーン。

インスタンス属性

インスタンス属性は、次のディレクトリに保存されます。

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

エントリ 説明
cluster-location

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

cluster-name

GKE クラスタの名前。

cluster-uid

GKE クラスタの UID。

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

クラスタ プロジェクトのメタデータは、次のディレクトリに保存されます。

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 サービス アカウントは、そのノードにデプロイされているすべてのワークロードで共有されます。その結果、権限が過剰にプロビジョニングされる可能性があります。これは、最小権限の原則に反し、マルチテナント クラスタでは不適切です。

次のステップ