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


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

始める前に

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

  • Google Kubernetes Engine API を有効にする。
  • Google Kubernetes Engine API の有効化
  • このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化する。すでに gcloud CLI をインストールしている場合は、gcloud components update を実行して最新のバージョンを取得する。

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

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

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

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

  1. 新しい 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 です。

  2. 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 トークンにアクセスできなくなります。

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

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

メタデータの隠蔽を有効にするには、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.1v1beta1 は、2020 年 9 月 30 日にサポート終了となり、停止されました。

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

次のステップ