Workload Identity を使用する

Autopilot スタンダード

このドキュメントでは、Google Kubernetes Engine（GKE）クラスタで Workload Identity を有効にして構成する方法を説明します。Workload Identity を使用すると、GKE クラスタ内のワークロードが Identity and Access Management（IAM）サービスアカウントに代わって Google Cloud サービスにアクセスできます。Workload Identity の仕組みの詳細については、Workload Identity をご覧ください。

制限事項

GKE は、Google Cloud プロジェクトごとに固定の Workload Identity プールを PROJECT_ID.svc.id.goog という形式で作成します。
Workload Identity はメタデータ隠蔽機能に代わるものです。メタデータ隠蔽機能で保護された機密メタデータは Workload Identity でも保護されます。
GKE がノードプールで GKE メタデータサーバーを有効にすると、Pod は Compute Engine メタデータサーバーにアクセスできなくなります。GKE メタデータサーバーは、ホストネットワークで実行されている Pod を除き、これらの Pod からメタデータエンドポイントへのリクエストをインターセプトします。
ホストネットワークで実行されている Pod で Workload Identity を使用することはできません。これらの Pod からメタデータエンドポイントへのリクエストは、Compute Engine のメタデータサーバーに転送されます。
GKE メタデータサーバーが新しく作成された Pod でのリクエストの承認を開始するまでに数秒かかります。したがって、Pod の有効期間の最初の数秒以内に Workload Identity を使用して認証を試みると、失敗する可能性があります。この問題は、呼び出しを再試行することで解決します。詳しくは、トラブルシューティングをご覧ください。
GKE の組み込みの Logging エージェントと Monitoring エージェントは、引き続きノードのサービスアカウントを使用します。
Workload Identity を有効にしても Cloud Run for Anthos がリクエスト指標のリリースを継続するには手動による設定が必要になります。
Workload Identity は、クラスタが --disable-default-snat フラグなしで作成された場合に ip-masq-agent をインストールします。
Workload Identity は、メモリの問題を回避するため、ノードごとに GKE メタデータサーバーへの接続を 200 に制限します。ノードがこの上限を超えると、タイムアウトが発生することがあります。
Windows Server ノードの Workload Identity は、GKE バージョン 1.18.16-gke.1200、1.19.8-gke.1300、1.20.4-gke.1500 以降で使用できます。
GKE メタデータサーバーは、クラスタ内の Kubernetes サービスアカウントの合計数に比例してメモリリソースを使用します。クラスタに 3,000 を超える Kubernetes サービスアカウントがある場合、kubelet はメタデータサーバー Pod を終了することがあります。緩和策については、トラブルシューティングをご覧ください。

始める前に

作業を始める前に、次のことを確認してください。

Google Kubernetes Engine API を有効にします。

Google Kubernetes Engine API の有効化

このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化します。
注: 既存の gcloud CLI のインストールでは、必ず compute/region と compute/zone のプロパティを設定してください。デフォルトのロケーションを設定することで、gcloud CLI のエラー（One of [--zone, --region] must be supplied: Please specify location など）を防止できます。

IAM Service Account Credentials API が有効になっているかを確認します。

IAM Credentials API を有効にする
次の IAM ロールがあることを確認します。
- roles/container.admin
- roles/iam.serviceAccountAdmin

Workload Identity を有効にする

Workload Identity は、Google Cloud CLI または Google Cloud コンソールを使用して、クラスタとノードプールで有効にできます。Workload Identity をノードプールで有効にするには、クラスタレベルで Workload Identity を有効にする必要があります。

Autopilot クラスタは、デフォルトで Workload Identity を有効にします。Workload Identity を使用するように Autopilot Pod を構成するには、Workload Identity を使用するようにアプリケーションを構成するに進んでください。

新しいクラスタの作成

Workload Identity は、gcloud CLI または Google Cloud コンソールを使用して新しい標準クラスタで有効にできます。

gcloud

新しいクラスタで Workload Identity を有効にするには、次のコマンドを実行します。

gcloud container clusters create CLUSTER_NAME \
    --region=COMPUTE_REGION \
    --workload-pool=PROJECT_ID.svc.id.goog

次のように置き換えます。

CLUSTER_NAME: 新しいクラスタの名前。
COMPUTE_REGION: クラスタの Compute Engine のリージョン。ゾーンクラスタの場合は、--zone=COMPUTE_ZONE を使用します。
PROJECT_ID: Google Cloud プロジェクト ID。

Console

新しいクラスタで Workload Identity を有効にする手順は、次のとおりです。

Google Cloud コンソールで [Google Kubernetes Engine] ページに移動します。
Google Kubernetes Engine に移動
残りの手順は、Google Cloud コンソールに自動的に表示されます。
[クラスタを作成] ダイアログで、GKE Standard の [構成] をクリックします。
ナビゲーションパネルの [クラスタ] の下の [セキュリティ] をクリックします。
[Workload Identity を有効にする] チェックボックスをオンにします。
必要に応じてクラスタを構成します。
[作成] をクリックします。

既存のクラスタを更新する

既存の標準クラスタでは、gcloud CLI または Google Cloud コンソールを使用して Workload Identity を有効にできます。既存のノードプールは影響を受けませんが、クラスタ内の新しいノードプールすべてでは Workload Identity が使用されます。

gcloud

既存のクラスタで Workload Identity を有効にするには、次のコマンドを実行します。

gcloud container clusters update CLUSTER_NAME \
    --region=COMPUTE_REGION \
    --workload-pool=PROJECT_ID.svc.id.goog

次のように置き換えます。

CLUSTER_NAME: 既存のクラスタの名前。
COMPUTE_REGION: クラスタの Compute Engine のリージョン。ゾーンクラスタの場合は、--zone=COMPUTE_ZONE を使用します。
PROJECT_ID: Google Cloud プロジェクト ID。

Console

既存のクラスタで Workload Identity を有効にする手順は、次のとおりです。

Google Cloud コンソールで [Google Kubernetes Engine] ページに移動します。
Google Kubernetes Engine に移動する
残りの手順は、Google Cloud コンソールに自動的に表示されます。
Google Kubernetes Engine ページのクラスタリストで、変更したいクラスタの名前をクリックします。
[詳細] タブで、[セキュリティ] セクションを見つけます。
[Workload Identity] フィールドで、 [Workload Identity を編集] をクリックします。
[Workload Identity の編集] ダイアログで、[Workload Identity を有効にする] チェックボックスをオンにします。
[Save Changes] をクリックします。

既存のワークロードを Workload Identity に移行する

既存のクラスタで Workload Identity を有効にした後、稼働中のワークロードを Workload Identity を使用するように移行する場合があります。ご使用の環境に適した移行方法を選択します。Workload Identity が有効になっている新しいノードプールを作成するか、Workload Identity を有効にするように既存のノードプールを更新できます。

Workload Identity との互換性を保つためにアプリケーションを変更する必要もある場合は、新しいノードプールを作成することをおすすめします。

新しいノードプールを作成する

クラスタで Workload Identity が有効になっている場合、作成するすべての新しいノードプールでは、デフォルトで Workload Identity が使用されます。Workload Identity が有効になっている新しいノードプールを作成するには、次のコマンドを実行します。

gcloud container node-pools create NODEPOOL_NAME \
    --cluster=CLUSTER_NAME \
    --workload-metadata=GKE_METADATA

次のように置き換えます。

NODEPOOL_NAME: 新しいノードプールの名前。
CLUSTER_NAME: Workload Identity が有効になっている既存のクラスタの名前。

--workload-metadata=GKE_METADATA フラグにより、GKE メタデータサーバーを使用するようにノードプールが構成されます。Workload Identity がクラスタで有効になっていない場合は、ノードプールの作成が失敗するようにこのフラグを含めることをおすすめします。

既存のノードプールを更新する

Workload Identity は、クラスタで Workload Identity を有効にした後、既存のノードプールで手動で有効にできます。

gcloud

Workload Identity が使用されるように既存のノードプールを変更するには、次のコマンドを実行します。

gcloud container node-pools update NODEPOOL_NAME \
    --cluster=CLUSTER_NAME \
    --workload-metadata=GKE_METADATA

クラスタで Workload Identity が有効になっている場合、--workload-metadata=GCE_METADATA を明示的に指定することで特定のノードプールで選択的に無効にできます。詳しくは、クラスタメタデータの保護をご覧ください。

Console

Workload Identity を使用するように既存のノードプールを変更する手順は、次のとおりです。

Google Cloud コンソールで [Google Kubernetes Engine] ページに移動します。
Google Kubernetes Engine に移動する
残りの手順は、Google Cloud コンソールに自動的に表示されます。
クラスタのリストで、変更するクラスタの名前をクリックします。
[ノード] タブをクリックします。
[ノードプール] セクションで、変更するノードプールの名前をクリックします。
[ノードプールの詳細] ページで、[編集] をクリックします。
[ノードプールの編集] ページの [セキュリティ] セクションで、[GKE メタデータサーバーを有効にする] チェックボックスをオンにします。
[保存] をクリックします。

Workload Identity を使用するようにアプリケーションを構成する

Workload Identity を有効にしたら、アプリケーションを新しいノードプールに移行する前に、Workload Identity を使用して Google Cloud への認証を行うようにアプリケーションを構成する必要があります。

Kubernetes サービスアカウントをアプリケーションに割り当て、その Kubernetes サービスアカウントが IAM サービスアカウントとして機能するように構成する必要があります。

次の手順は、クラスタで Workload Identity が有効になっている場合に、Workload Identity を使用するようにアプリケーションを構成する方法を示したものです。

クラスタの認証情報を取得します。
```
gcloud container clusters get-credentials CLUSTER_NAME
```
CLUSTER_NAME は、Workload Identity が有効になっているクラスタの名前に置き換えます。
Kubernetes サービスアカウントに使用する Namespace を作成します。デフォルトの Namespace を使用することも、既存の Namespace を使用することもできます。
```
kubectl create namespace NAMESPACE
```
アプリケーションで使用する Kubernetes サービスアカウントを作成します。また、デフォルトの Namespace または既存の Namespace で、デフォルトの Kubernetes サービスアカウントを使用することもできます。
```
kubectl create serviceaccount KSA_NAME \
    --namespace NAMESPACE
```
次のように置き換えます。
- KSA_NAME: 新しい Kubernetes サービスアカウントの名前。
- NAMESPACE: サービスアカウントの Kubernetes Namespace の名前。
アプリケーションに IAM サービスアカウントを作成するか、既存の IAM サービスアカウントを使用します。組織内の任意のプロジェクトで、任意の IAM サービスアカウントを使用できます。Config Connector の場合は、選択したサービスアカウントに IAMServiceAccount オブジェクトを適用します。
gcloud
gcloud CLI を使用して新しい IAM サービスアカウントを作成するには、次のコマンドを実行します。

注: gcloud CLI で既存の IAM サービスアカウントを使用している場合は、この手順をスキップします。
```
gcloud iam service-accounts create GSA_NAME \
    --project=GSA_PROJECT
```
以下を置き換えます。
- GSA_NAME: 新しい IAM サービスアカウントの名前。
- GSA_PROJECT: IAM サービスアカウントの Google Cloud プロジェクトのプロジェクト ID。
Config Connector
Config Connector で新規または既存の IAM サービスアカウントを使用するには、次の構成ファイルを適用します。

注: 既存の IAM サービスアカウントを使用している場合でも、kubectl を使用してクラスタに IAMServiceAccount オブジェクトを適用する必要があります。構成ファイルの GSA_NAME は、使用するサービスアカウントの名前に置き換えます。
注: この手順には Config Connector が必要です。Config Connector をクラスタにインストールするには、インストール手順を実施してください。

GitHub で表示
```
apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMServiceAccount
metadata:
  name: [GSA_NAME]
spec:
  displayName: [DISPLAY_NAME]
```
このマニフェストをデプロイするには、service-account.yaml という名前でマシンにダウンロードします。

kubectl を使用してマニフェストを適用します。
```
kubectl apply -f service-account.yaml
```
IAM サービスアカウントから Google Cloud APIs へのアクセスを承認する方法については、サービスアカウントについてをご覧ください。
必要なロールが IAM サービスアカウントにあることを確認します。次のコマンドを使用して、追加のロールを付与できます。
```
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com" \
    --role "ROLE_NAME"
```
次のように置き換えます。
- PROJECT_ID: Google Cloud プロジェクト ID。
- GSA_NAME: IAM サービスアカウントの名前。
- GSA_PROJECT: IAM サービスアカウントの Google Cloud プロジェクトのプロジェクト ID。
- ROLE_NAME: roles/spanner.viewer など、サービスアカウントに割り当てる IAM ロール。
2 つのサービスアカウントの間に IAM ポリシーバインディングを追加して、Kubernetes サービスアカウントが IAM サービスアカウントの権限の借用できるようにします。このバインドでは、Kubernetes サービスアカウントが IAM サービスアカウントとして機能します。
gcloud
```
gcloud iam service-accounts add-iam-policy-binding GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com \
    --role roles/iam.workloadIdentityUser \
    --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]"
```
Config Connector
注: この手順には Config Connector が必要です。Config Connector をクラスタにインストールするには、インストール手順を実施してください。

GitHub で表示
```
apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicy
metadata:
  name: iampolicy-workload-identity-sample
spec:
  resourceRef:
    apiVersion: iam.cnrm.cloud.google.com/v1beta1
    kind: IAMServiceAccount
    name: [GSA_NAME]
  bindings:
    - role: roles/iam.workloadIdentityUser
      members:
        - serviceAccount:[PROJECT_ID].svc.id.goog[[K8S_NAMESPACE]/[KSA_NAME]]
```
このマニフェストをデプロイするには、policy-binding.yaml という名前でマシンにダウンロードします。GSA_NAME、PROJECT_ID、NAMESPACE、KSA_NAME を、実際の環境での値に置き換えます。次のコマンドを実行します。
```
kubectl apply -f policy-binding.yaml
```
IAM サービスアカウントのメールアドレスで Kubernetes サービスアカウントにアノテーションを付けます。
kubectl
```
kubectl annotate serviceaccount KSA_NAME \
    --namespace NAMESPACE \
    iam.gke.io/gcp-service-account=GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com
```
yaml
```
apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    iam.gke.io/gcp-service-account: GSA_NAME@PROJECT_ID.iam.gserviceaccount.com
  name: KSA_NAME
  namespace: NAMESPACE
```
注: このアノテーションだけでは、IAM サービスアカウントの権限借用に必要なアクセス権は付与されません。IAM バインディングが存在しない場合、Pod は IAM サービスアカウントを使用できません。
Workload Identity を使用するノード上のワークロードをスケジュール設定して、アノテーション付きの Kubernetes サービスアカウントを使用するように、Pod の仕様を更新します。

注: デフォルトの Kubernetes サービスアカウントにアノテーションを付ける場合は、spec.serviceAccountName を省略します。Autopilot クラスタの場合は、nodeSelector フィールドを省略します。すべてのノードが Workload Identity を使用するため、Autopilot は、この nodeSelector を拒否します。
```
spec:
  serviceAccountName: KSA_NAME
  nodeSelector:
    iam.gke.io/gke-metadata-server-enabled: "true"
```
更新された構成をクラスタに適用します。
```
kubectl apply -f DEPLOYMENT_FILE
```
DEPLOYMENT_FILE は、更新された Pod 仕様へのパスに置き換えます。

Workload Identity の設定を確認する

サービスアカウントが正しく構成されていることを確認します。Kubernetes サービスアカウントを使用して、OS 固有のコンテナイメージを実行する Pod を作成し、インタラクティブなセッションで Pod に接続します。

Linux

アノテーション付きの Kubernetes サービスアカウントを使用し、service-accounts エンドポイントを curl する Pod を作成します。

次の構成を wi-test.yaml として保存します。
```
apiVersion: v1
kind: Pod
metadata:
  name: workload-identity-test
  namespace: NAMESPACE
spec:
  containers:
  - image: google/cloud-sdk:slim
    name: workload-identity-test
    command: ["sleep","infinity"]
  serviceAccountName: KSA_NAME
  nodeSelector:
    iam.gke.io/gke-metadata-server-enabled: "true"
```
google/cloud-sdk イメージには Google Cloud CLI が含まれており、Google Cloud APIs を簡単に利用できます。イメージのダウンロードに時間がかかる場合があります。

注: Autopilot クラスタの場合は、nodeSelector フィールドを省略します。すべてのノードが Workload Identity を使用しているため、Autopilot は、この nodeSelector を拒否します。
Pod を作成します。
```
kubectl apply -f wi-test.yaml
```

Pod でインタラクティブセッションを開きます。

kubectl exec -it workload-identity-test \
  --namespace NAMESPACE \
  -- /bin/bash

Pod 内で次のコマンドを実行します。
```
curl -H "Metadata-Flavor: Google" http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/email
```
サービスアカウントが正しく構成されている場合、IAM サービスアカウントのメールアドレスがアクティブな唯一の ID になります。デフォルトでは、Google Cloud APIs を呼び出すときに Pod が IAM サービスアカウントの権限として動作します。

Windows

servercore コンテナイメージを実行する Kubernetes サービスアカウントを使用して Pod を作成します。

次のマニフェストを保存します。

apiVersion: v1
kind: Pod
metadata:
  name: workload-identity-test
  namespace: NAMESPACE
spec:
  containers:
  - image: IMAGE_NAME
    name: workload-identity-test
    command: ["powershell.exe", "sleep", "3600"]
  serviceAccountName: KSA_NAME
  nodeSelector:
    kubernetes.io/os: windows
    cloud.google.com/gke-os-distribution: windows_ltsc
    iam.gke.io/gke-metadata-server-enabled: "true"

IMAGE_NAME を、次のいずれかのコンテナサーバーコアイメージの値に置き換えます。

Windows Server ノードイメージコンテナ servercore イメージ

WINDOWS_LTSC、
WINDOWS_LTSC_CONTAINERD mcr.microsoft.com/windows/servercore:ltsc2019

Windows Server ノードイメージ	コンテナ `servercore` イメージ
`WINDOWS_LTSC`、 `WINDOWS_LTSC_CONTAINERD`	`mcr.microsoft.com/windows/servercore:ltsc2019`
`WINDOWS_SAC`, `WINDOWS_SAC_CONTAINERD`	警告: Microsoft は SAC のサポートを終了するため、Windows Server Semi-Annual Channel（SAC）イメージは 2022 年 8 月 9 日以降はサポートされません。考えられる影響と移行手順については、Windows Server Semi-Annual Channel のサポート終了をご覧ください。 GKE ノードバージョンと Windows SAC バージョンの間のバージョンマッピングを確認します。Windows Server バージョン 1909 の場合は `mcr.microsoft.com/windows/servercore:1909` を指定し、それ以外の場合は `mcr.microsoft.com/windows/servercore:20H2` を指定します。

WINDOWS_SAC,
WINDOWS_SAC_CONTAINERD

GKE ノードバージョンと Windows SAC バージョンの間のバージョンマッピングを確認します。Windows Server バージョン 1909 の場合は mcr.microsoft.com/windows/servercore:1909 を指定し、それ以外の場合は mcr.microsoft.com/windows/servercore:20H2 を指定します。

Pod でインタラクティブセッションを開きます。

kubectl exec -it workload-identity-test \
  --namespace NAMESPACE -- powershell

Pod 内で次の powershell コマンドを実行します。
```
Invoke-WebRequest  -Headers @{"Metadata-Flavor"="Google"} -Uri  http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/email  -UseBasicParsing
```
サービスアカウントが正しく構成されている場合、IAM サービスアカウントのメールアドレスがアクティブな唯一の ID になります。デフォルトでは、Google Cloud APIs を呼び出すときに Pod が IAM サービスアカウントの権限を使用します。

コードから Workload Identity を使用する

コードで Google Cloud サービスに対する認証を行うプロセスは、Compute Engine のメタデータサーバーを使用した認証と同じです。Workload Identity を使用すると、インスタンスメタデータサーバーに対するリクエストが GKE メタデータサーバーに転送されます。インスタンスメタデータサーバーを使用して認証する既存のコードは（Google Cloud クライアントライブラリを使用したコードと同様）、変更せずにそのまま使用できます。

Workload Identity で別のプロジェクトから割り当てを使用する

GKE バージョン 1.24 以降を実行しているクラスタでは、Google Cloud API を呼び出すときに、必要に応じて別の Google Cloud プロジェクトの割り当てを使用するように Kubernetes サービスアカウントを構成できます。これにより、メインプロジェクトでは割り当て全体を使用せず、クラスタ内のさまざまなサービスには他のプロジェクトからの割り当てを使用できます。

Workload Identity を使用して割り当てプロジェクトを構成するには、次の手順に従います。

割り当てプロジェクトの serviceusage.services.use 権限を Kubernetes サービスアカウントに付与します。
```
gcloud projects add-iam-policy-binding \
--role=roles/serviceusage.serviceUsageConsumer \
--member=serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME] \
QUOTA_PROJECT_ID
```
QUOTA_PROJECT_ID は、割り当てプロジェクトのプロジェクト ID に置き換えます。

割り当てプロジェクトで Kubernetes サービスアカウントにアノテーションを付けます。

kubectl annotate serviceaccount KSA_NAME \
--namespace NAMESPACE \
iam.gke.io/credential-quota-project=QUOTA_PROJECT_ID

構成が正しく機能することを確認するには、次の手順に従います。

Workload Identity の設定を確認するの手順に沿って、Pod を作成してシェルセッションを開始します。

サービスアカウントトークンリクエストを作成します。

curl -H "Metadata-Flavor: Google" http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/token

Google Cloud Console で、割り当てプロジェクトの IAM Service Accounts Credentials API ページに移動します。

[API] に移動
トラフィックの変化を確認します。

クリーンアップ

Workload Identity の使用を停止するには、IAM サービスアカウントへのアクセス権を取り消して、クラスタの Workload Identity を無効にします。

アクセスの取り消し

IAM サービスアカウントへのアクセス権を取り消します。
gcloud
```
gcloud iam service-accounts remove-iam-policy-binding GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com \
    --role roles/iam.workloadIdentityUser \
    --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]"
```
次のように置き換えます。
- PROJECT_ID: GKE クラスタのプロジェクト ID。
- NAMESPACE: Kubernetes サービスアカウントが配置されている Kubernetes Namespace の名前。
- KSA_NAME: アクセス権が取り消される Kubernetes サービスアカウントの名前。
- GSA_NAME: IAM サービスアカウントの名前。
- GSA_PROJECT: IAM サービスアカウントのプロジェクト ID。
Config Connector
Config Connector を使用してサービスアカウントを作成した場合は、kubectl を使用してサービスアカウントを削除します。
```
kubectl delete -f service-account.yaml
```
キャッシュ内のトークンの有効期限は 30 分です。キャッシュ内のトークンが期限切れになっているかどうかは、次のコマンドで確認できます。
```
gcloud auth list
```
このコマンドの出力に GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com が含まれない場合は、キャッシュ内のトークンはすでに期限切れです。
Kubernetes サービスアカウントからアノテーションを削除します。IAM によってアクセス権が取り消されたため、このステップは省略可能です。
```
kubectl annotate serviceaccount KSA_NAME \
    --namespace NAMESPACE iam.gke.io/gcp-service-account-
```
注: アノテーションを削除しないと、Workload Identity で使用する IAM サービスアカウントが gcloud auth list の実行時に引き続き表示されることがあります。ただし、GKE は Google Cloud サービスの認証に IAM サービスアカウントを使用しません。

Workload Identity を無効にする

Workload Identity は GKE Standard クラスタでのみ無効にできます。

gcloud

各ノードプールで Workload Identity を無効にします。
```
gcloud container node-pools update NODEPOOL_NAME \
    --cluster=CLUSTER_NAME \
    --workload-metadata=GCE_METADATA
```
クラスタ内の各ノードプールに対してこのコマンドを繰り返します。

クラスタで Workload Identity を無効にします。

gcloud container clusters update CLUSTER_NAME \
    --disable-workload-identity

Console

Google Cloud コンソールで [Google Kubernetes Engine] ページに移動します。
Google Kubernetes Engine に移動する
残りの手順は、Google Cloud コンソールに自動的に表示されます。
Google Kubernetes Engine ページのクラスタリストで、変更したいクラスタの名前をクリックします。
[ノード] タブをクリックします。
特定のノードプールの Workload Identity を無効にするには、ノードプールごとに次の操作を行います。
1. [ノードプール] セクションで、変更するノードプールの名前をクリックします。
2. [ノードプールの詳細] ページで、[編集] をクリックします。
3. [ノードプールの編集] ページの [セキュリティ] セクションで、[GKE メタデータサーバーを有効にする] チェックボックスをオフにします。
4. [保存] をクリックします。
クラスタの Workload Identity を無効にする手順は次のとおりです。
1. [詳細] タブをクリックします。
2. [セキュリティ] セクションで、[Workload Identity] の横にある [ 編集] をクリックします。
3. [Workload Identity の編集] ダイアログで、[Workload Identity を有効にする] チェックボックスをオフにします。
[Save Changes] をクリックします。

組織内で Workload Identity を無効にする

セキュリティの観点から、Workload Identity では GKE が、Kubernetes サービスアカウント ID を Google Cloud リソースに対して認証、認可できるものとして表明できるようになっています。サービスアカウント作成の無効化やサービスアカウントキーの作成の無効化など、ワークロードを Google Cloud リソースから分離するための措置を講じた管理者は、組織の Workload Identity を無効にする場合もあります。

組織の Workload Identity を無効にする手順をご覧ください。

トラブルシューティング

トラブルシューティング情報については、Workload Identity のトラブルシューティングをご覧ください。

次のステップ

Workload Identity の詳細を確認する。
GKE セキュリティの概要を確認する。
クラスタメタデータの保護について確認する。
IAM サービスアカウントについて学習する。

Workload Identity を使用する

制限事項

始める前に

Workload Identity を有効にする

新しいクラスタの作成

gcloud

Console

既存のクラスタを更新する

gcloud

Console

既存のワークロードを Workload Identity に移行する

新しいノードプールを作成する

既存のノードプールを更新する

gcloud

Console

Workload Identity を使用するようにアプリケーションを構成する

gcloud

Config Connector

gcloud

Config Connector

kubectl

yaml

Workload Identity の設定を確認する

Linux

Windows

コードから Workload Identity を使用する

Workload Identity で別のプロジェクトから割り当てを使用する

クリーンアップ

アクセスの取り消し

gcloud

Config Connector

Workload Identity を無効にする

gcloud

Console

組織内で Workload Identity を無効にする

トラブルシューティング

次のステップ