すべてのプロダクト
Search

このプロダクト

    Container Service for Kubernetes:リモートアテステーションによる機密コンテナー環境の保護

    ドキュメントセンター

    Container Service for Kubernetes:リモートアテステーションによる機密コンテナー環境の保護

    最終更新日:Dec 27, 2025

    PeerPod リモートアテステーションは、機密コンテナーが Intel TDX などの、信頼でき改ざんされていない機密コンピューティング環境で実行されることを保証します。デプロイ前にノードの整合性を自動的に検証し、アプリケーションが実行時にオンデマンドで環境のアテステーションをフェッチできるようにすることで、機密性の高いワークロードにエンドツーエンドのセキュリティ保証を提供します。

    仕組み

    機密コンピューティングのリモートアテステーションは、PeerPod コンテナーのために、検証可能でハードウェアによって保護されたランタイム環境を作成し、外部からの攻撃から保護します。このメカニズムは、リモートアテステーションサービス (以下、Trustee) をトラストアンカーとして使用し、Pod のライフサイクルの 2 つの重要な段階、つまりデプロイ時と実行時に環境の整合性をチェックします。

    ユースケース 1：起動前の環境検証

    このプロセスは、クラスター管理者が Pod を信頼できる本物の機密環境でのみ起動できるように設計されています。ワークフロー全体は自動化されており、手動での介入は不要です。

    1. デプロイの開始：管理者は、Pod マニフェストをクラスターの API サーバーに送信してワークロードを作成します。次に、ノード上の kubelet は、Container Runtime Interface (CRI) を介して containerd に Pod サンドボックスの作成をリクエストします。containerd は Pod の runtimeClassName をチェックし、基盤となる Kata Remote ランタイム kata-runtime を呼び出します。

    2. 機密 VM の作成：Kata Remote はリクエストに応答し、Alibaba Cloud OpenAPI を呼び出して、軽量でハードウェア的に分離された ECS TDX 機密 VM を起動します。これが Kubernetes Pod として機能します。

    3. 必須のリモートアテステーション：イメージがプルされる前に、VM 内の Attestation Agent がハードウェア署名を含むランタイム環境のエビデンスを自動的に生成し、検証のために Trustee サービスに送信します。

    4. 検証とワークロードの実行：Trustee がエビデンスの有効性を確認した後にのみ、ゲストの制御ロジックはアプリケーションイメージのプルやコンテナーの起動を含む後続の操作に進みます。

    ユースケース 2：実行時のリモートアテステーション

    この機能は、コンテナー化されたアプリケーション向けのもので、アプリケーションが自らの実行環境のセキュリティを外部サービスに積極的に証明し、システムをまたいだ信頼の連鎖を構築できるようにします。

    1. アプリケーションによるエビデンスのフェッチ：コンテナー内のアプリケーションは、http://127.0.0.1:8006/aa/evidence のローカル API 操作を呼び出すことで、リアルタイムのリモートアテステーションレポートをリクエストします。

    2. 外部サービスによる検証：アプリケーションはこのエビデンスを外部サービス (コンシューマー) に送信します。サービスコンシューマーは、そのエビデンスを自身の信頼する Trustee サービスに転送して検証します。検証が成功すると、通信相手が保護された機密環境で実行されていることが証明され、動的に信頼が確立されます。

    image

    前提条件

    1. ご利用のクラスターで CAA ソリューションが有効になっていること。詳細については、「CAA を使用して機密 VM 上に機密コンテナーをデプロイする」をご参照ください。

    2. 信頼できる環境に Trustee サービスをインストールし、その IP アドレスを記録します (これがご利用の Trustee サービスエンドポイントになります)。次のコマンドを使用して Trustee をインストールできます。

      クラスター内の PeerPod は、リモートアテステーションを完了するためにこの IP アドレスにアクセスできる必要があります。Trustee のネットワークが CAA クラスターの Pod VPC からルーティング可能であることを確認してください。

      次のコマンドを実行して Trustee をインストールします。このトピックでは Alibaba Cloud Linux 3 を使用し、Trustee の IP アドレスの例は 1.2.3.4 です。

      yum install trustee -y

    3. Trustee サーバーで、セキュリティグループルールを追加して、TCP ポート 8080 でのインバウンドトラフィックを許可します。このルールのソースは、CAA クラスターの Pod が Trustee にアクセスするために使用する Egress IP アドレスである必要があります。

      • CAA クラスターと Trustee が同じ VPC にある場合は、VPC の CIDR ブロックからのトラフィックを許可します。

      • VPC 間またはインターネット経由で通信する場合は、クラスターの NAT Gateway のパブリック Egress IP アドレスからのトラフィックを許可します。

    ユースケース 1：信頼できる環境へのコンテナーの検証とデプロイ

    この手順では、コンテナーのデプロイ段階でリモートアテステーションを実行し、ワークロードが検証済みの信頼できるノードでのみ実行されることを保証します。

    1. Trustee の設定

    Trustee サーバーで、どの環境特性が信頼できると見なされるかを定義するポリシーを設定します。

    1. コンテナーセキュリティ起動ポリシーを設定します。

      このポリシーファイルは機密リソースとして扱われ、TDX Pod の起動プロセス中に読み込まれ、リモートアテステーションフローをトリガーします。

      # ポリシーを保存するディレクトリを作成
mkdir -p /opt/trustee/kbs/repository/default/container-policy

# すべてのイメージを許可するポリシーファイルを作成 (デモ目的のみ)
cat << EOF > /opt/trustee/kbs/repository/default/container-policy/insecure-accept-all
{
    "default": [{"type": "insecureAcceptAnything"}],
    "transports": {}
}
EOF

    2. リモートアテステーションポリシーを設定します。

      このポリシーは、信頼できるハードウェアおよびソフトウェア環境の具体的な基準を定義します。例えば、環境が Intel TDX プラットフォームで実行されていることを要求できます。

      # ポリシーファイル /opt/trustee/attestation-service/policies/opa/default.rego を変更
# 内容を ECS TDX PeerPod のリモートアテステーションポリシーに置き換え
cat << EOF > /opt/trustee/attestation-service/policies/opa/default.rego
package policy

import rego.v1

default executables := 32
default hardware := 97
default configuration := 32
default file_system := 32

##### ECS TDX PeerPod
executables := 3 if {
	input.tdx
}

hardware := 2 if {
	# エビデンスが Intel TDX タイプであることを検証
	input.tdx.quote.header.tee_type == "81000000"
	# ベンダー ID を検証
	input.tdx.quote.header.vendor_id == "939a7233f79c4ca9940a0db3957f0607"
}

configuration := 2 if {
	input.tdx
}

file_system := 2 if {
	input.tdx
}
EOF

    3. Trustee サービスを再起動してポリシーを適用します。

      service as restart

    2. リモートアテステーションを有効にした Pod のデプロイ

    1. initdata を準備し、Pod をデプロイします。

      initdata は、Trustee サービスアドレスなどの設定情報を PeerPod に渡すために使用されます。

      # 実際の Trustee IP アドレスに置き換え
TRUSTEE_SERVICE_ENDPOINT=1.2.3.4

# initdata.toml ファイルを生成
cat <<EOF > initdata.toml
version = "0.1.0"
algorithm = "sha256"
[data]
"aa.toml" = '''
[eventlog_config]
enable_eventlog = true
[token_configs]
[token_configs.kbs]
url = "http://${TRUSTEE_SERVICE_ENDPOINT}:8080"
'''
"cdh.toml" = '''
[kbc]
name = "cc_kbc"
url = "http://${TRUSTEE_SERVICE_ENDPOINT}:8080"
[image]
image_security_policy_uri = "kbs:///default/container-policy/insecure-accept-all"
'''
EOF

# initdata を gzip で圧縮し、Base64 でエンコード
initdata=$(cat initdata.toml | gzip | base64 -w0)
      echo $initdata を実行して、initdata のエンコードされた内容を表示します。

    2. Pod の YAML ファイルを作成します。

      前のステップで生成した initdata 文字列を、Pod のメタデータの annotations フィールドに書き込みます。

      # pod.yaml という名前のファイルを作成
cat << EOF > pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-caa-demo
  annotations:
    io.katacontainers.config.hypervisor.cc_init_data: ${initdata}
spec:
  runtimeClassName: kata-remote
  containers:
    - image: alibaba-cloud-linux-3-registry.cn-hangzhou.cr.aliyuncs.com/alinux3/alinux3:latest
      name: hello
      command: ["sh", "-c", "echo hello && sleep infinity"]
EOF

    3. Pod をデプロイします。

      kubectl apply -f pod.yaml

      デプロイ後、kubectl get po pod-caa-demo を実行して Pod のステータスを確認します。

    4. Trustee サーバーでリモートアテステーションのステータスを検証します。

      リモートアテステーションサービスのログをチェックして、環境の検証が成功したことを確認します。

      journalctl -u as -f

      ログに Tdx Verifier/endorsement check passed というメッセージが表示された場合、リモートアテステーションが成功し、Pod が信頼できる環境で起動したことを示します。

    ユースケース 2：コンテナー実行時に環境の信頼性をフェッチして検証

    このユースケースは、すでに PeerPod 内で実行されているアプリケーションが、自身の実行環境のアテステーションレポートを動的に取得し、独立した外部サービスによって検証させるまでの完全なワークフローを示します。

    このプロセスには、3 つの異なる実行環境が関わります：

    • ローカルターミナル：クラスターと対話するために使用するマシン。

    • Pod コンテナー内：機密アプリケーションが実行され、アテステーションレポートを生成する場所。kubectl exec -it pod-caa-demo -- sh を実行してコンテナーに入ることができます。

    • 検証サーバー：Trustee サービスがデプロイされている、独立した信頼できるサーバーノード。このサーバーは、受信したエビデンスを検証する責任を負います。この目的のために、既存の Trustee を再利用するか、新しいものをデプロイすることができます。

    1. コンテナー内からのリモートアテステーションエビデンスの取得

    (任意) ステップ 1：動的メジャーメントの追加

    動的メジャーメントにより、アプリケーションはカスタムのランタイム情報をリモートアテステーションレポートに埋め込むことができ、これにより監査およびコンプライアンス機能が強化されます。

    標準のリモートアテステーションが「金庫」自体のセキュリティを検証するのに対し、動的メジャーメントは「金庫の中身」も期待される状態にあることをさらに証明します。

    Pod コンテナー内から、API http://127.0.0.1:8006/aa/aael に HTTP POST リクエストを送信して、情報を動的に記録します。この情報は、基盤となる TDX Pod の Eventlog に保存され、改ざんを防ぐために最終的なアテステーションレポートに紐付けられます。

    • リクエストボディ：

      domain、operation、および content フィールドはすべてカスタマイズ可能で、印字可能な文字列です。スペースを含めることはできません。
      {
  "domain": "<DOMAIN>",
  "operation": "<OPERATION>",
  "content": "<CONTENT>"
}

    • 例：設定読み込みイベントの記録

      # このコマンドをコンテナー内で実行
curl -X POST http://127.0.0.1:8006/aa/aael \
     -H "Content-Type: application/json" \
     -d '{"domain":"test","operation":"test","content":"test"}'

    ステップ 2：リモートアテステーションエビデンスの取得

    Pod コンテナー内から、HTTP GET リクエストを送信して、現在の信頼できる実行環境 (TEE) のリモートアテステーションエビデンスを取得し、外部の当事者による検証に供します。

    http://127.0.0.1:8006/aa/evidence に GET リクエストを送信します。

    runtime_data パラメーターには、リプレイ攻撃から保護するために検証者が提供する Base64 エンコードされたチャレンジ値 (Nonce) を含める必要があります。
    curl 127.0.0.1:8006/aa/evidence?runtime_data=AAAA

    このコマンドは長い JSON 文字列を出力します。これが現在の TEE のリモートアテステーションエビデンスです。この文字列全体 (開始の { から終了の } まで) をコピーし、次のステップのために一時ファイルに保存します。

    2. 検証環境の準備

    検証プロセスは、独立した信頼できる Trustee インスタンスに依存します。

    1. (任意) yum install trustee -y を実行して、検証サーバーに Trustee をインストールします。

    2. クライアント側の検証ポリシーを設定します。

      検証ノードで、Trustee サービスに新しいポリシーファイル /opt/trustee/attestation-service/policies/opa/client.rego を作成します。

      # client.rego ファイルを以下の内容で作成
cat <<EOF > /opt/trustee/attestation-service/policies/opa/client.rego

# 機密コンテナー (TEE) から取得したエビデンスを検証するポリシー
package policy
import rego.v1

# --- デフォルトスコア ---
default executables := 32
default hardware := 97
default configuration := 32
default file_system := 32

# --- Alibaba Cloud ECS TDX PeerPod の検証ルール ---
# 例：スコア 2 = "信頼できる", 3 = "肯定的"
# 入力エビデンスに "tdx" フィールドが含まれている場合、ソフトウェアスタックは "肯定的" と見なされる
executables := 3 if {
    input.tdx
}

# ハードウェアのスコアリングルール：以下の両方の条件が満たされた場合、ハードウェア環境は "信頼できる" (スコア 2) と評価される
hardware := 2 if {
    # TEE タイプフィールドをチェック。Intel TDX の識別子 "81000000" である必要がある
    input.tdx.quote.header.tee_type == "81000000"

    # ベンダー ID フィールドをチェック。公式の Intel UUID である必要がある
    input.tdx.quote.header.vendor_id == "939a7233f79c4ca9940a0db3957f0607"
}

# 入力が TDX エビデンスの場合、その構成は "信頼できる" と見なされる
configuration := 2 if {
    input.tdx
}

# 入力が TDX エビデンスの場合、そのファイルシステムは "信頼できる" と見なされる
file_system := 2 if {
    input.tdx
}
EOF

    3. Trustee を再起動して client.rego ポリシーを適用します。

      service as-restful restart

    3. 検証リクエストの準備と送信

    コンテナーから取得したエビデンスを検証サービスに送信します。

    1. (推奨) 元のエビデンスを安全に保存します。

      特殊文字によるエラーを避けるため、エビデンスをファイルに保存することを推奨します。

      # evidence.json という名前の一時ファイルを作成
cat > evidence.json

      コマンドを実行した後、完全な JSON 文字列を貼り付けます。その後、ファイルを保存して編集モードを終了します。

    2. ファイルからエビデンスを読み取り、リクエストを準備します。

      # ファイルの内容を変数に読み込む
EVIDENCE=$(cat evidence.json)

# エビデンスを Base64 エンコードし、URL セーフにする
BASE64EVIDENCE=$(echo ${EVIDENCE} | base64 -w 0 2>/dev/null | tr '+/' '-_' | tr -d '=' )

# エンコードされたエビデンスを含むリクエストボディファイルを作成
cat << EOF > request.json
{
    "verification_requests": [
        {
            "tee": "tdx",
            "evidence": "${BASE64EVIDENCE}"
        }
    ],
    "policy_ids": ["client"]
}
EOF

    3. 検証リクエストを送信します。
      ローカル検証サービスの /attestation エンドポイントに、デフォルトポート 50005 で POST リクエストを送信します。

      curl -k -X POST http://127.0.0.1:50005/attestation \     -i \     -H 'Content-Type: application/json' \     -d @request.json

      レスポンスボディには、JWT 文字列である token フィールドが含まれます。これが検証トークンです。このトークンをコピーしてください。

    4. 検証結果の解析と評価

    JWT トークンを解析して、現在の環境の各サブステートの信頼性スコアを取得します。

    1. 検証トークンを保存します。

      # '<...>' を取得した実際の JWT 文字列 (引用符なし) に置き換えます
TOKEN='<ここに JWT トークンを貼り付け>'

    2. トークンを解析し、スコアを表示します。

      echo $TOKEN | cut -d'.' -f2 | base64 -d |  jq '.submods.cpu0."ear.trustworthiness-vector"'

      期待される出力：

      base64: invalid input
{
  "configuration": 2,
  "executables": 3,
  "file-system": 2,
  "hardware": 2
}

      • base64: invalid input メッセージは無視して問題ありません。

      • JSON の内容は検証結果を示しています。スコアはポリシーファイルで定義した値と一致しており、コンテナーが準拠した信頼できる TDX 環境で実行されていることを確認します。検証は成功です。

    本番環境への適用

    • アテステーションポリシーの精密化：この例では緩いポリシーを使用しています。本番環境では、特定のハードウェアプラットフォームとソフトウェアスタックに一致する正確な Rego ポリシーを作成する必要があります。これらのポリシーは、監査と変更追跡のためにバージョン管理システムで管理する必要があります。

    • 認証情報とキーの管理：initdata.toml ファイルには機密性の高い設定が含まれる可能性があります。情報漏洩を防ぐために、その生成、配布、および保管を厳格に管理してください。