Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

Confidential GKE Node で vTPM と認証情報にアクセスする

Standard

Confidential Google Kubernetes Engine Node で実行するワークロードは、仮想トラステッドプラットフォームモジュール（vTPM）や Confidential Computing 証明書レポートなどのプラットフォームの完全性とセキュリティ機能にアクセスして使用できます。このドキュメントでは、セキュリティエンジニアが vTPM とハードウェアベースのデバイスを GKE ワークロードに公開して、リモート証明、シークレットシーリング、乱数生成などのタスクを実行する方法について説明します。

次のリソースについて理解しておく必要があります。

使用する Confidential Computing テクノロジーは、組織の脅威モデルとセキュリティ要件によって異なります。詳細については、 Confidential Computing テクノロジーをご覧ください。

Confidential Computing のタスク

Confidential GKE Node で実行される Pod から vTPM とハードウェアモジュールにアクセスできます。これらのモジュールを使用して、シークレットシーリングなどの暗号オペレーションやリモート証明を実行できます。これらのタスクに使用される特定のモジュールは、ノードが使用する Confidential Computing テクノロジーによって異なります。

シークレットシーリング: すべての Confidential Computing テクノロジーで、ワークロードは Shielded VM vTPM をルートオブトラストとしてシークレットシーリングに使用できます。
リモート証明: ワークロードは、リモート証明に次のいずれかのモジュールを使用できます。
- AMD SEV: Shielded VM vTPM。
- AMD SEV-SNP: ハードウェアベースの AMD Secure Processor。
- Intel TDX: ハードウェアベースの Intel TDX モジュール。
これらの Confidential Computing テクノロジーでのリモート証明の仕組みについて詳しくは、証明者のアーキテクチャと証拠をご覧ください。

始める前に

始める前に、次のタスクが完了していることを確認してください。

Google Kubernetes Engine API を有効にする。

Google Kubernetes Engine API の有効化

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

要件セクションのすべての条件を満たすクラスタまたはノードプールで、Confidential GKE Node を有効にします。詳細については、クラスタレベルで Confidential GKE Node を構成するまたはノードプールレベルで Confidential GKE Node を構成するをご覧ください。

要件

Confidential GKE Node は、次の条件で使用できます。

アクセスする Confidential Computing モジュールに応じて、クラスタとノードプールで次のいずれかのバージョンを実行する必要があります。
- vTPMs: 任意の GKE バージョン。
- AMD SEV-SNP ハードウェアベースのデバイス: GKE バージョン 1.33.5-gke.1350000 以降、またはバージョン 1.34.1-gke.2037000 以降。
- Intel TDX ハードウェアベースのデバイス: GKE バージョン 1.33.5-gke.1697000 以降、またはバージョン 1.34.1-gke.2909000 以降。
ノードプールは、対応するマシンタイプがある Compute Engine ロケーションに配置する必要があります。リージョンでの提供状況について詳しくは、マシンタイプ、CPU、ゾーンをご覧ください。
ノードでは Container-Optimized OS ノードイメージを使用する必要があります。

デバイスプラグインをインストールする

完全性とセキュリティ情報を GKE Pod に公開するには、デバイスプラグインをインストールします。DaemonSet を使用してプラグインをインストールする手順は次のとおりです。

クラスタに接続します。
```
gcloud container clusters get-credentials CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION
```
次のように置き換えます。
- CLUSTER_NAME: クラスタの名前。
- CONTROL_PLANE_LOCATION: クラスタコントロールプレーンのリージョンまたはゾーン（us-central1、us-central1-a など）。

cc-device-plugin DaemonSet を作成します。

kubectl create -f https://raw.githubusercontent.com/google/cc-device-plugin/main/manifests/cc-device-plugin.yaml

DaemonSet を作成すると、Confidential GKE Node の Confidential Computing デバイスが、それらのノードで実行される Pod に公開されます。

Pod から Confidential Computing デバイスにアクセスする

デバイスプラグインをインストールする DaemonSet を作成したら、Kubernetes で他の拡張リソースをリクエストする場合と同様に、Pod から vTPM とハードウェアベースのデバイスにアクセスできます。以降のセクションでは、任意の Pod から vTPM にアクセスする方法と、AMD SEV-SNP ノードと Intel TDX ノードでハードウェアベースのモジュールにアクセスする方法について説明します。

Pod から vTPM にアクセスする

Confidential GKE Node で実行される任意の Pod から Shielded VM vTPM にアクセスするには、google.com/cc デバイスをコンテナのリソース上限に追加します。次の手順では、Pod の vTPM へのアクセスをリクエストします。

次の Pod マニフェストを example-vtpm-pod.yaml として保存します。

apiVersion: v1
kind: Pod
metadata:
name: my-vtpm-pod
spec:
containers:
- name: test-vtpm
  image: ubuntu
  command: ["/bin/sh", "-c", "ls -l /dev/tpmrm0; sleep 3600"]
  ports:
  - containerPort: 8080
    name: http
  resources:
    limits:
      google.com/cc: 1

Pod を作成します。
```
kubectl apply -f example-vtpm-pod.yaml
```
Pod は /dev/tpmrm0 デバイスにアクセスします。
Pod が vTPM にアクセスできることを確認するには、Pod のログを確認します。
```
kubectl logs my-vtpm-pod
```
出力にファイル情報が含まれている場合、Pod はデバイスにアクセスできます。

アプリケーションコードからデバイスを操作できます。たとえば、 Go-TPM ライブラリを使用して vTPM と通信し、シーリングなどのタスクを実行できます。AMD SEV を使用する場合は、vTPM を使用して Confidential VM インスタンスのリモート証明を行うこともできます。

Pod からハードウェアベースのモジュールにアクセスする

AMD SEV-SNP または Intel TDX を使用する場合は、コンテナのリソース上限に対応するセレクタを指定することで、Pod 内の対応するハードウェアベースのモジュールにアクセスすることもできます。これらのテクノロジーでは vTPM が測定のルートオブトラストではないため、これらのモジュールを使用して AMD SEV-SNP と Intel TDX を使用するノードのリモート認証を行う必要があります。

次の手順では、AMD Secure Processor または Intel TDX モジュールへのアクセスをリクエストする方法について説明します。

次の Pod の例のいずれかを保存します。

AMD SEV-SNP デバイスをリクエストする:

apiVersion: v1
kind: Pod
metadata:
  name: snp-test-pod
spec:
  containers:
  - name: test-container
    image: alpine
    command: ["/bin/sh", "-c"]
    args:
      - |
        echo "Checking for SEV-SNP device..."
        ls -l /dev/sev-guest
        echo "SNP container started successfully"
        sleep 3600
    resources:
      limits:
        amd.com/sev-snp: "1"
      requests:
        amd.com/sev-snp: "1"
  nodeSelector:
    cloud.google.com/gke-confidential-nodes-instance-type: SEV_SNP

Intel TDX デバイスをリクエストする:

apiVersion: v1
kind: Pod
metadata:
  name: tdx-test-pod
spec:
  containers:
  - name: test-container
    image: alpine
    command: ["/bin/sh", "-c"]
    args:
      - |
        echo "Checking for TDX device..."
        ls -l /dev/tdx*
        echo "TDX container started successfully"
        sleep 3600
    resources:
      limits:
        intel.com/tdx: "1"
      requests:
        intel.com/tdx: "1"
  nodeSelector:
    cloud.google.com/gke-confidential-nodes-instance-type: TDX

Pod を作成します。
```
kubectl create -f PATH_TO_POD_MANIFEST
```
PATH_TO_POD_MANIFEST は、保存した Pod マニフェストファイルのパスに置き換えます。

Pod は次のいずれかのデバイスにアクセスします。
- AMD SEV-SNP の場合は /dev/sev-guest。
- Intel TDX の場合は /dev/tdx_guest。
Pod がデバイスにアクセスできることを確認するには、Pod のログを確認します。
```
kubectl logs POD_NAME
```
POD_NAME は、前の手順でデプロイした Pod の名前に置き換えます。

出力にファイル情報が含まれている場合、Pod はデバイスにアクセスできます。

次のステップ

ワークロードがConfidential VM で実行されていることをリモートで証明する方法を学習する。

Confidential GKE Node で vTPM と認証情報にアクセスする コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。