情報管理技術士 学習ノート
← 一覧へ
セキュリティ・個人情報
#ConfidentialContainers#CoCo#ConfidentialComputing#TEE#Kubernetes#KataContainers#RemoteAttestation#KeyBrokerService#PeerPods
最終更新 · 2026-09-27

Confidential Containers(CoCo)によるKubernetes機密ワークロード保護

1. 概要

A. 定義

Confidential Containers(CoCo)とは、Kubernetes Podをハードウェアに基づくTrusted Execution Environment(TEE)内で実行し、処理中のデータとワークロードのコードをホスト基盤、ハイパーバイザー、他のテナントから保護するクラウドネイティブな機密コンピューティング方式である。

通常のコンテナはプロセスとファイルシステムを隔離するが、ホストカーネルを共有する。強い権限を持つクラウド運用者やホスト管理者は、メモリを調べたり、イメージレイヤーをコピーしたり、デバッグ機能を悪用したりできる。ディスク暗号化と通信暗号化だけでは、アプリケーションがメモリ上で平文を処理する瞬間を保護できない。

CoCoはKata Containersの軽量VM隔離と、AMD SEV-SNPやIntel TDXのようなハードウェアによるメモリ暗号化・完全性機能を組み合わせる。リモート検証者が測定値を確認した後にだけイメージ復号鍵や秘密を渡すため、単なるコンテナのオプションではなく、隔離・測定・検証・秘密配送をつなぐワークロードの信頼チェーンになる。

B. 背景と必要性

クラウドでは、インフラ提供者とデータ所有者が一致しないことが多い。金融機関がパブリッククラウドで分析したり、複数企業がデータを共同処理したりする場合、運用者を完全に信頼せずに業務を行う必要がある。CoCoはKubernetesの運用性を保ちながら、機密データとモデルをインフラの信頼境界から分離する選択肢を提供する。

生成AIとデータ協業では、入力だけでなくプロンプト、モデル重み、処理結果も保護しなければならない。署名付きイメージは出所と完全性を示すが、内容の秘匿性は提供しない。暗号化イメージ、リモートアテステーション、条件付き鍵配送を一つのライフサイクルとして設計する必要がある。

CoCoは標準的なKubernetesの流れも維持する。runtimeClassNameで保護ランタイムを選び、OCIイメージと通常のスケジューリングを利用できる。ただし、すべてのPodが自動的に安全になるわけではなく、コントロールプレーン、レジストリ、KBS、ログ、ストレージには別々の信頼境界設計が必要である。

C. 範囲

第一の目的は、使用中のデータ(data in use)の機密性と実行コードの完全性である。保存データはストレージ暗号化、通信データはTLS、処理状態はTEEのメモリ暗号化で守る。アテステーションは判断の証拠であり、暗号化そのものの代替ではない。

保護領域は通常、ワークロードPodと限定されたゲストヘルパーである。APIサーバー、コントロールプレーン、ホストカーネル、ハイパーバイザー、他のPodは境界の外側にあり、非信頼として扱う。この範囲を明確にすることで、ノード全体が保護されるという過大な主張を避けられる。

2. 脅威モデルと信頼境界

A. 脅威の仮定

CoCoは、クラウドのホスト管理者や悪意あるハイパーバイザーがゲストの実行を観察・変更しようとする状況を想定する。また、攻撃者がノードのランタイムを掌握し、イメージレイヤーをコピーし、Kubernetesのデバッグやexecを悪用する可能性も考える。このモデルはアプリケーションの脆弱性や悪意あるコードを解決しないため、承認済みイメージとポリシーが前提になる。

代表的な脅威は、メモリの開示、ホストストレージからのイメージと秘密の盗難、ゲスト起動イメージの置換、ログ・一時ボリューム・過大なデバッグ権限による運用上の漏えいである。

flowchart LR
    U[Workload Pod] --> G[Guest helper and Kata agent]
    G --> T[TEE boundary]
    T --> H[Encrypted guest memory]
    H -. untrusted .-> HV[Hypervisor]
    HV -. untrusted .-> N[Host kernel and node]
    N -. untrusted .-> CP[Kubernetes control plane]
    CP -. untrusted .-> O[Other pods]

プロジェクトの設計では、ワークロードPodと補助プロセスをenclaveの中に置き、ハイパーバイザー、他のPod、コントロールプレーンを外に置く。これはTCBが大きくなりやすいノード中心方式と、通常の共有が複雑になるコンテナ中心方式の中間である。

Pod中心方式では、同一Podのコンテナがネットワーク名前空間とボリュームを共有でき、通常の通信をenclaveの外へ出さずに済む。ゲストAPIを比較的小さく保ちながら、Kubernetesのデプロイ単位も維持できる。

TEEはアプリケーションを安全にする魔法ではない。脆弱なアプリケーション、悪意あるイメージ、弱いRBAC、危険なネットワーク経路は依然として脅威である。イメージ分析、アプリケーションセキュリティ、Kubernetes認可、ネットワークポリシーをCoCoと重ね合わせる必要がある。

区分 信頼境界 主な責任
機密領域 ワークロードPodとゲストヘルパー アプリケーション実行と秘密の利用
検証層 TEE測定値とアテステーションエージェント 実行証拠の生成
鍵配送層 KBS、アテステーションサービス、ポリシー 証拠の検証と配送判断
プラットフォーム ハイパーバイザー、ホスト、他のPod 資源提供、原則として非信頼
制御領域 API、CI/CD、レジストリ、運用者 承認、監査、ポリシー変更

3. 構成要素と処理フロー

A. アーキテクチャ

sequenceDiagram
    participant Dev as Developer or CI
    participant K8s as Kubernetes API
    participant Kata as Kata runtime and Pod VM
    participant TEE as TEE guest
    participant AS as Attestation service
    participant KBS as Key Broker Service
    participant Reg as Registry
    Dev->>K8s: Deploy Pod with RuntimeClass
    K8s->>Kata: Start confidential Pod VM
    TEE->>AS: Send hardware and guest evidence
    AS-->>KBS: Return appraisal result
    KBS->>TEE: Release image key and secrets
    TEE->>Reg: Pull encrypted or signed image
    TEE-->>K8s: Run workload and report status

Kata Containersは共有ホストカーネルだけに依存せず、軽量VMの中でPodを動かす。CoCoはハードウェアTEEと、機密データハブやアテステーションエージェントをゲストに追加する。Kata Agentはゲスト内でコンテナのライフサイクルを管理するため、そのポリシーとイメージも測定対象に含めなければならない。

アテステーションエージェントはハードウェアとゲスト状態の証拠を作る。証拠にはTEE種別、ゲストイメージのダイジェスト、初期化データ、ランタイム設定などを含められる。検証者は証拠が存在するだけで信頼せず、ハードウェア署名、証明書チェーン、許可された測定値、TCBの基準を確認する。

Trustee型の構成では、Attestation Serviceが証拠を検証し、Key Broker Service(KBS)がワークロードに渡す秘密を決める。Confidential Data Hubはゲストの要求を仲介し、アプリケーションがKBSプロトコルを直接実装しないようにする。判断と実行を分離できるが、ポリシー版と判断ログを追跡可能にしなければならない。

B. リモートアテステーションと条件付き配送

通常はnonceを含むchallengeから始まる。TEEが現在の実行環境について署名付き証拠を生成し、Attestation Serviceが署名・証明書チェーン・測定値・appraisal policyを検査する。合格した場合だけKBSがイメージ鍵や秘密を配送し、失敗したゲストは暗号化イメージを起動できない。

ポリシーを「TEEなら許可」とだけ書いてはいけない。TEE種別、ゲストダイジェスト、Kata Agentポリシー、コンテナイメージ、namespace、ワークロードID、目的、期限に鍵を結び付ける。モデル鍵なら、承認済みGPU TEEと特定イメージの一致を同時に要求できる。

アテステーションは永続的な証明書ではない。再起動、イメージ変更、TCBパッチ、鍵の期限、ポリシー更新時には再検証する。長時間動作するサービスではセッション鍵やleaseの更新が必要であり、証拠やログに個人情報と平文の秘密を記録してはならない。

C. イメージと秘密の保護

署名付きイメージは出所と完全性の確認に向くが、レジストリ運用者から内容を隠さない。モデル重みや営業データの機密性が必要なら、アテステーション成功後にだけ復号鍵を取得する暗号化レイヤーを利用する。

guest-pull方式では、ホストランタイムが平文レイヤーを展開しない。ゲストが証明を通過してKBSから鍵を受け取り、機密境界内でイメージを取得・復号・検証する。レジストリ資格情報も範囲を限定し、同じ信頼モデルで管理しなければならない。

Kubernetes Secretを環境変数へ注入すると、ログ、コアダンプ、デバッグツールから漏れる可能性がある。KBSのリソースポリシーをワークロードIDに結び付け、必要な時だけ短期資格情報を渡す方式が望ましい。

D. Kubernetes連携

CoCoはRuntimeClassで保護ランタイムを選ぶ。通常Podは既定ランタイムを使い、機密Podはkata-qemu-snpやkata-qemu-tdxのようなクラスを指定する。スケジューラはTEE対応ノードのラベルと資源を考慮し、意図しない非機密実行を防ぐ必要がある。

Admissionポリシーでは、許可イメージ、必須RuntimeClass、デバッグ制限、ノードラベル、namespace、サービスアカウントを検査する。Pod内の全コンテナとinit containerを一つの保護境界として確認し、例外には所有者、理由、期限、承認記録を付ける。

4. 配備方式と比較

A. ローカルPod VMとPeer Pods

ローカルPod VM方式は、worker node上でKata VMを作り、TEE対応の物理または仮想化環境を利用する。直接制御できる反面、ファームウェア、入れ子仮想化、デバイスパススルー、ノード交換を管理する必要がある。

Peer Pods方式では、Cloud API AdaptorがクラウドAPIを呼び出して外部の機密VMを作る。TEEベアメタルノードの必要性を下げられるが、API遅延、ネットワークとストレージ、外部VM費用、追加の障害ドメインが発生する。

項目 ローカルPod VM Peer Pods
VMの場所 Kubernetes worker node クラウドAPIが作る外部VM
長所 ノードと資源を直接制御 既存クラスタで提供者TEEを利用
主な負担 TEEノード、ファームウェア、デバイス API遅延、ネットワーク、VM費用
適した環境 管理されたオンプレミス・エッジ パブリッククラウド・マルチテナント
共通条件 アテステーション、鍵配送、イメージポリシーが必要 アテステーション、鍵配送、イメージポリシーが必要

B. 通常コンテナ、Kata、CoCo

通常コンテナは密度と起動速度に優れるが、ホスト管理者からの機密性を保証しない。KataはVM隔離を加えるが、イメージ秘匿とリモートアテステーションが常に一体になるわけではない。CoCoはKataの境界にハードウェア測定と条件付き秘密配送を加える。

その代わり、VM起動、証明、鍵交換、運用のコストが増える。GPU、CSIストレージ、高速ネットワーク、デバッグ機能がTEE境界と衝突することもあるため、通常・Kata・CoCoのプロファイルをリスクに応じて併用するのが現実的である。

5. 適用事例

金融機関の共同特徴量分析では、各機関が入力と承認済み分析イメージを暗号化してCoCoへ配置する。TEE測定値、イメージダイジェスト、分析目的が一致したときだけKBSが復号鍵を渡す。TEEがあっても分析結果の再識別リスクは残るため、出力制限を別途適用する。

製造業のAI推論サービスでは、モデル重みと入力データを暗号化し、CPUとGPUの測定値が承認された場合にだけモデル鍵を配送するcomposite attestationを検討できる。ただしGPUパススルー、ドライバ、CUDA、モデルローダーもTCBや検証基準に含まれる。

マルチテナントSaaSでは、テナント鍵をテナントID、処理目的、短期leaseに結び付ける。通常のexecを拒否し、承認済み診断イメージとマスキング済みチャネルを用意する。CoCoはインフラへの信頼を下げるが、アプリケーションの認可やテナント分離を代替しない。

6. 発展 — 成熟度と答案構成

CoCoはハードウェアごとに異なるTEEをKubernetesのワークロードモデルへ抽象化するオープンソースの取り組みである。CPU、GPU、クラウド、Kata、Trustee、CSI、ネットワークの対応状況は版によって異なるため、導入前に公式リリースノートとハードウェア対応表を確認する。

技術士の論述では、保存時・通信時の暗号化だけではdata in useを守れないという問題を先に示す。次にPod中心の境界とTEEを説明し、Kata runtime、attestation、KBS、暗号化イメージの流れを図示する。その後、通常コンテナ・Kata・CoCoを機密性、完全性、性能、運用難度で比較し、鍵ポリシー、供給網、可観測性、例外、性能検証へ結び付ける。

TEEがすべての攻撃を防ぐと書いてはいけない。TEEはホストによるメモリ検査への強い境界を提供するが、アプリケーションの欠陥、悪意あるイメージ、弱い鍵ポリシー、危険なログ、サービス拒否は自動的に解決しない。

7. 考慮事項と示唆

A. TCBと測定範囲の最小化

ゲストカーネル、Kata Agent、初期化データ、ドライバ、GPU部品を最小化し、版とビルドハッシュを管理する。reference valueの変更にはセキュリティレビューとロールバックを設け、緊急パッチと通常リリースを分ける。

B. 鍵管理とポリシーの分離

KBSは単なる秘密保管庫ではなく、証拠を評価するポリシー実行点である。鍵をイメージダイジェスト、ワークロードID、目的、環境、期限に結び付け、管理者にも平文鍵が見えない階層を設計する。

C. 供給網の保護

ゲストとコンテナのイメージを再現可能にビルドし、SBOM、署名、脆弱性検査、出所証明をCI/CDへつなぐ。署名は完全性と出所を補うが秘匿性は提供しないため、必要なら暗号化イメージも利用する。

D. 性能・可用性と障害モード

アテステーションと鍵交換はPod起動時間を増加させる。起動遅延、レジストリ往復、KBS障害、TEE資源をSLOに含め、新規Podはfail-closedにするか、既存Podを継続させるかを事前に決める。

E. 可観測性と安全なデバッグ

機密情報を含めず、証明結果、ポリシー版、イメージダイジェスト、RuntimeClass、鍵配送結果を構造化して記録する。メモリダンプとリモートexecは原則無効にし、非機密の再現環境と承認済み診断イメージを別に用意する。

F. 規制と責任境界

CoCoは個人・金融・医療データの技術的保護を強化するが、適法な目的、最小化、保存期間の規律に代わるものではない。証明ポリシー、reference value、ハードウェア、クラウド事業者の責任を契約と運用手順で明確にする。

一言まとめ: Confidential ContainersはKataによるPod隔離、ハードウェアTEE、リモートアテステーション、条件付き鍵配送を組み合わせ、非信頼インフラ上でもKubernetesの使用中データとワークロードコードを保護する方式である。

参考資料