クラスタメタデータの保護

Standard

Google Kubernetes Engine（GKE）ではインスタンスメタデータを使用してノード仮想マシン（VM）を構成しますが、このメタデータの一部は潜在的に機密性が高く、クラスタで実行中のワークロードから保護する必要があります。

始める前に

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

Google Kubernetes Engine API を有効にする。

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

ノードのサービスアカウントの構成

各ノードのサービスアカウントの認証情報は引き続きワークロードに公開されます。デフォルトでは、ノードは Compute Engine のデフォルトのサービスアカウントを使用します。Compute Engine のデフォルトのサービスアカウントの代わりに、ノードに対して最小限の権限のサービスアカウントを構成する必要があります。次に、このサービスアカウントをノードに接続して、攻撃者が Compute Engine API を使用して、基盤となる VM インスタンスに直接アクセスすることで GKE メタデータ保護を回避することができないようにします。

詳しくは、最小権限のサービスアカウントを使用するをご覧ください。

最小限の権限のノードサービスアカウントを作成するには、次の操作を行います。

新しい Identity and Access Management（IAM）サービスアカウントを作成し、そのメールアドレスを環境変数に保存します。
```
gcloud iam service-accounts create NODE_SA_NAME \
    --display-name="DISPLAY_NAME"
export NODE_SA_EMAIL=$(gcloud iam service-accounts list --format='value(email)' \
    --filter='displayName:DISPLAY_NAME')
```
次のように置き換えます。
- NODE_SA_NAME: 新しいノードサービスアカウントの名前。
- DISPLAY_NAME: 新しいサービスアカウントの表示名。
ノードサービスアカウントのメールアドレスの形式は NODE_SA_NAME@PROJECT_ID.iam.gserviceaccount.com です。

GKE ノードを実行するための最小限のロールと権限でサービスアカウントを構成します。

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:$NODE_SA_EMAIL \
    --role=roles/monitoring.metricWriter
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:$NODE_SA_EMAIL \
    --role=roles/monitoring.viewer
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:$NODE_SA_EMAIL \
    --role=roles/logging.logWriter

PROJECT_ID は、実際の Google Cloud プロジェクト ID に置き換えます。

さらに、クラスタが Artifact Registry から非公開イメージを pull する場合は、roles/artifactregistry.reader ロールを追加します。

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:$NODE_SA_EMAIL \
    --role=roles/artifactregistry.reader

メタデータ隠蔽

GKE のメタデータ隠蔽により、ユーザー Pod は、kubelet 認証情報を含む kube-env と、VM のインスタンス ID トークンにアクセスできなくなります。

メタデータ隠蔽は、ユーザー Pod（HostNetwork 上で実行されていない Pod）からクラスタメタデータサーバーへのトラフィックをファイアウォール制御し、安全なクエリのみを許可します。ファイアウォールは、ユーザー Pod により、権限昇格攻撃に kubelet 認証情報が使用されるのを防ぎます。また、インスタンスエスカレーション攻撃に VM ID が使用されるのも防ぎます。

Workload Identity Federation for GKE はメタデータ隠蔽の使用に代わるもので、メタデータ隠蔽が提供する保護を拡張します。すべての状況で、メタデータ隠蔽ではなく Workload Identity Federation for GKE を使用する必要があります。詳細については、Workload Identity Federation for GKE についてをご覧ください。

メタデータ隠蔽を有効にするには、gcloud beta container clusters create コマンドまたは gcloud beta container node-pools create コマンドで非推奨の --workload-metadata=SECURE オプションを使用します。

制限事項

メタデータ隠蔽には、次のような制限があります。

メタデータ隠蔽は、kube-env とノードのインスタンス ID トークンへのアクセスのみを保護します。
メタデータ隠蔽は、ノードのサービスアカウントへのアクセスを制限しません。
メタデータ隠蔽は、他の関連するインスタンスメタデータへのアクセスを制限しません。
メタデータ隠蔽は、その他の以前のメタデータ API へのアクセスを制限しません。
メタデータ隠蔽では、ホストネットワーク（Pod 仕様の hostNetwork: true）で実行されている Pod からのトラフィックは制限されません。

以前のメタデータ API の無効化と移行

Compute Engine メタデータサーバーエンドポイント v0.1 と v1beta1 は、2020 年 9 月 30 日にサポート終了となり、停止されました。

停止スケジュールについては、v0.1 と v1beta1 メタデータサーバーエンドポイントのサポート終了をご覧ください。

次のステップ

クラスタで GKE 用 Workload Identity 連携を有効にする。