Azure Kubernetes Service での機密コンテナーのセキュリティ ポリシー
Confidential Computing Consortium (CCC) によって説明されているように、"機密コンピューティングとは、ハードウェアベースで構成証明済みの高信頼実行環境 (TEE) で計算を実行することによる、使用中のデータの保護です"。AKS の機密コンテナーは、使用中の Kubernetes ポッドのデータを、これらのポッドの外部から行われる不正アクセスから保護するように設計されています。 各ポッドは、AMD SEV-SNP TEE によって保護されたユーティリティ VM (UVM) 内で、使用中のデータを暗号化することでホスト オペレーティング システム (OS) によるデータへのアクセスを防止しながら実行されます。 Microsoft のエンジニアは、オープンソース コミュニティである Confidential Containers (CoCo) および Kata Containers と協力して、機密コンテナーの設計と実装を行いました。
セキュリティ ポリシーの概要
Kata Containers システム アーキテクチャの主要コンポーネントの 1 つは、Kata エージェントです。 Kata Containers を使って機密コンテナーを実装すると、エージェントはハードウェア ベースの TEE 内で実行されるため、ポッドのトラステッド コンピューティング ベース (TCB) の一部になります。 次の図に示すように、Kata エージェントは一連の ttrpc API を提供して、TEE の外部のシステム コンポーネントが機密ベースの Kubernetes ポッドを作成して管理することを可能にします。 これらの他のコンポーネント (Kata Shim など) は、ポッドの TCB の一部ではありません。 そのため、エージェントは、バグや悪意の可能性がある API 呼び出しからそれ自体を保護する必要があります。
AKS 機密コンテナーでは、Kata エージェント API の自己保護は、機密ポッドの所有者が指定するセキュリティ ポリシー (Kata "エージェント ポリシー" とも呼ばれます) を使って実装されます。 ポリシーのドキュメントには、業界標準の Rego ポリシー言語を使って、各ポッドに対応するルールとデータが含まれています。 ユーティリティ VM (UVM) 内でのポリシーの適用は、Cloud Native Computing Foundation (CNCF) の段階的なプロジェクトである Open Policy Agent (OPA) を使用して実装されます。
ポリシーの内容
セキュリティ ポリシーでは、機密ポッドの作成と管理に必要なエージェントの ttrpc API に対するすべての呼び出し (および、これらの API 呼び出しのパラメーター) が記述されています。 各ポッドのポリシー ドキュメントはテキスト ファイルで、Rego 言語が使われています。 ポリシー ドキュメントには、3 つの上位セクションがあります。
データ
ポリシー データは、ポッドごとに固有です。 それには、たとえば次のものが含まれます。
- ポッドに作成される必要があるコンテナーの一覧。
- ポリシーによって既定でブロックされる API の一覧 (秘密保持のため)。
ポッドの各コンテナーのポリシー ドキュメントに含まれるデータの例:
- イメージの整合性情報。
- コンテナーで実行されるコマンド。
- 記憶域のボリュームとマウント。
- 実行セキュリティ コンテキスト。 たとえば、ルート ファイル システムは読み取り専用か?
- プロセスによる新しい特権の取得は許可されるか?
- 環境変数。
- Open Container Initiative (OCI) コンテナーの実行時構成のその他のフィールド。
ルール
Rego 形式で指定されたポリシー ルールは、ユーティリティ VM (UVM) の外部からの Kata エージェント API 呼び出しごとに OPA によって実行されます。 エージェントはすべての API 入力を OPA に提供し、OPA はルールを使って入力がポリシー データと一致するかどうかを調べます。 ポリシー ルールとデータで API 入力が許可されない場合、エージェントは "ポリシーによってブロックされました" というエラー メッセージを返して API 呼び出しを拒否します。 次にルールの例をいくつか示します。
- 各コンテナー レイヤーは、読み取り専用の virtio ブロック デバイスとしてユーティリティ VM (UVM) に公開されます。 それらのブロック デバイスの整合性は、Linux カーネルの dm-verity テクノロジを使って保護されます。 ポリシー データには dm-verity ハッシュ ツリーのルートで予期される値が含まれており、実行時にポリシー ルールによって検証されます。
- 予期されないコマンド ライン、ストレージ マウント、実行セキュリティ コンテキスト、または環境変数が検出されると、ルールはコンテナーの作成を拒否します。
既定では、ポリシーのルールはすべてのポッドに共通です。 genpolicy ツールはポリシー データを生成し、各ポッドに固有です。
既定の値
ポリシー データと API 入力をパラメーターとして使って Rego ルールを評価するとき、OPA は、入力データに基づいて true 値を返すルールのセットを少なくとも 1 つ見つけようとします。 ルールが true を返さない場合、OPA はその API の既定値をエージェントに返します。 ポリシーの既定値の例:
default CreateContainerRequest := false: ポリシー ルールのセットによってその呼び出しが明示的に許可されない限り、すべての CreateContainer API 呼び出しが拒否されることを意味します。default GuestDetailsRequest := true: この API によって返されるデータは顧客のワークロードの機密性に影響しないので、TEE の外部からの GuestDetails API に対する呼び出しは常に許可されることを意味します。
Kata エージェントへのポリシーの送信
すべての AKS 機密コンテナー ユーティリティ VM (UVM) は、ユーティリティ VM (UVM) ルート ファイル システム内に含まれる一般的な既定のポリシーを使用して起動します。 そのため、実行時には、実際の顧客ワークロードと一致するポリシーをエージェントに提供する必要があります。 ポリシー テキストは先ほど説明したように YAML マニフェスト ファイル内に埋め込まれることで、ユーティリティ VM (UVM) の初期化中の早い段階でエージェントに提供されます。 ポリシーの注釈は、AKS 機密コンテナー システムの kubelet、containerd、kata shim コンポーネントを経由します。 その後、エージェントは OPA と連携して、独自の API へのすべての呼び出しにポリシーを適用します。
ポリシーは、TCB の一部ではないコンポーネントを使って提供されるため、このポリシーは最初は信頼されません。 次のセクションで説明するように、リモート構成証明を通じてポリシーの信頼性を確立する必要があります。
ポリシー ドキュメントで信頼を確立する
Kata shim は、ユーティリティ VM (UVM) を作成する前に、ポリシー ドキュメントの SHA256 ハッシュを計算して、そのハッシュ値を TEE にアタッチします。 このアクションにより、ポリシーの内容とユーティリティ VM (UVM) の間に強力なバインディングが作成されます。 この TEE フィールドをユーティリティ VM (UVM) の内部または外部で実行されるソフトウェアが後になって変更することはできません。
エージェントは、ポリシーを受け取ると、ポリシーのハッシュが不変の TEE フィールドと一致することを確認します。 エージェントは、ハッシュの不一致を検出した場合、受け取ったポリシーを拒否します。
ワークロードは、機密情報を処理する前に、リモート構成証明の手順を実行して、予期されるバージョンの TEE、OS、エージェント、OPA、ルート ファイル システムを使ってワークロードが実行されていることを、証明書利用者に証明する必要があります。 構成証明は、AMD SEV-SNP ハードウェアから署名された構成証明の証拠を取得するユーティリティ VM (UVM) の内部で実行されるコンテナー内に実装されます。 構成証明の証拠のフィールドの 1 つは、前に説明したポリシー ハッシュ TEE フィールドです。 そのため、構成証明サービスは、このフィールドの値とポッド ポリシーの予期されるハッシュを比較して、ポリシーの整合性を確認できます。
ポリシーの適用
Kata エージェントは、ポリシーを適用する責任があります。 Microsoft は、各エージェントの ttrpc API 呼び出しについてポリシーをチェックするエージェント コードを、Kata と CoCo のコミュニティに提供しました。 エージェントは、API に対応するアクションを実行する前に、OPA REST API を使って、ポリシー ルールとデータによって呼び出しが許可またはブロックされるかどうかを調べます。