Share via


Azure Kubernetes Service 上の機密コンテナーのセキュリティ ポリシー

コンフィデンシャル コンピューティング コンソーシアム (CCC) で説明されているように、「コンフィデンシャル コンピューティングは、ハードウェア ベースの構成証明された信頼された実行環境 (T Enterprise Edition) で計算を実行することによって、使用中のデータの保護です。AKS Confidential Containers は、使用中の Kubernetes ポッド データを、これらのポッドの外部からの不正アクセスから保護するように設計されています。 各ポッドは、使用中のデータを暗号化して AMD Standard Edition V-SNP T Enterprise Edition によって保護された機密仮想マシン (CVM) で実行され、ホスト オペレーティング システム (OS) によるデータへのアクセスを防止します。 Microsoft のエンジニアは、Confidential Containers (CoCo) および Kata Containers オープンソース コミュニティと協力して、機密コンテナーの設計と実装を行いました。

セキュリティ ポリシーの概要

Kata Containers システム アーキテクチャのメイン コンポーネントの 1 つが Kata エージェントです。 Kata Containers を使用して機密コンテナーを実装する場合、エージェントはハードウェア ベースの T Enterprise Edition 内で実行されるため、ポッドのトラステッド コンピューティング ベース (TCB) の一部になります。 次の図に示すように、Kata エージェントには、T Enterprise Edition の外部にあるシステム コンポーネントが CVM ベースの Kubernetes ポッドを作成および管理できる一連の ttrpc API が用意されています。 これらの他のコンポーネント (Kata Shim など) は、ポッドの TCB の一部ではありません。 そのため、エージェントは、バグが生じる可能性がある API 呼び出しや悪意のある API 呼び出しから自身を保護する必要があります。

Diagram of the AKS Confidential Containers security policy model.

AKS Confidential Containers では、Kata エージェント API の自己保護は、機密ポッドの所有者によって指定されたセキュリティ ポリシー (Kata エージェント ポリシーとも呼ばれます) を使用して実装されます。 ポリシー ドキュメントには、業界標準 の Rego ポリシー言語を使用して、各ポッドに対応するルールとデータが含まれています。 CVM 内でのポリシーの適用は、クラウド ネイティブ コンピューティング基盤 (CNCF) の卒業プロジェクトである Open Policy Agent (OPA) を使用して実装されます。

ポリシーの内容

セキュリティ ポリシーは、Confidential ポッドの作成と管理に必要なエージェントの ttrpc API (およびこれらの API 呼び出しのパラメーター) へのすべての呼び出しを記述します。 各ポッドのポリシー ドキュメントは、Rego 言語を使用したテキスト ファイルです。 ポリシー ドキュメントには、3 つの大まかなセクションがあります。

データ

ポリシー データは、各ポッドに固有です。 これには次のものが含まれます。

  • ポッドに作成される必要があるコンテナーの一覧。
  • 既定でポリシーによってブロックされている API の一覧 (機密性の理由から)。

ポッド内の各コンテナーのポリシー ドキュメントに含まれるデータの例:

  • イメージの整合性情報。
  • コンテナーで実行されるコマンド。
  • ストレージ ボリュームとマウント。
  • 実行セキュリティ コンテキスト。 たとえば、ルート ファイル システムは読み取り専用ですか?
  • プロセスは新しい特権を取得できますか?
  • 環境変数。
  • Open Container Initiative (OCI) コンテナー ランタイム構成のその他のフィールド。

ルール

Rego 形式で指定されたポリシー ルールは、CVM の外部からの Kata エージェント API 呼び出しごとに OPA によって実行されます。 エージェントは OPA にすべての API 入力を提供し、OPA はルールを使用して、入力がポリシー データと一致するかどうかをチェックします。 ポリシー ルールとデータで API 入力が許可されていない場合、エージェントは "ポリシーによってブロックされました" というエラー メッセージを返すことによって API 呼び出しを拒否します。 ルールの例をいくつか次に示します。

  • 各コンテナー レイヤーは、読み取り専用 の virtio ブロック デバイスとして CVM に公開されます。 これらのブロック デバイスの整合性は、Linux カーネルの dm-verity テクノロジを使用して保護されます。 dm-verity ハッシュ ツリー の予想されるルート値はポリシー データに含まれており、ポリシー ルールによって実行時に検証されます。
  • 予期しないコマンド ライン、ストレージ マウント、実行セキュリティ コンテキスト、または環境変数が検出されると、ルールによってコンテナーの作成が拒否されます。

既定では、ポリシー ルール はすべてのポッドに共通です。 genpolicy ツールはポリシー データを生成し、各ポッドに固有です。

既定の値

ポリシー データと API 入力をパラメーターとして使用して Rego ルールを評価する場合、OPA は、入力データに基づいて値を返す true ルールのセットを少なくとも 1 つ検索しようとします。 ルールが返 trueされない場合、OPA はその API の既定値をエージェントに返します。 ポリシーの既定値の例:

  • default CreateContainerRequest := false – ポリシー規則のセットで明示的にその呼び出しが許可されていない限り、すべての CreateContainer API 呼び出しが拒否されることを意味します。

  • default GuestDetailsRequest := true– これは、T Enterprise Edition から GuestDetails API への呼び出しが常に許可されることを意味します。これは、この API によって返されるデータが、顧客のワークロードの機密性に対して機密性がないためです。

Kata エージェントへのポリシーの送信

すべての AKS Confidential Containers CVM は、CVMs ルート ファイル システムに含まれる一般的な既定のポリシーを使用して起動します。 そのため、実際の顧客のワークロードに一致するポリシーは、実行時にエージェントに提供する必要があります。 ポリシー テキストは、前述のように YAML マニフェスト ファイルに埋め込まれており、CVM の初期化中の早い段階でエージェントにこの方法で提供されます。 ポリシー注釈は、AKS Confidential Containers システムの kubelet、containerd、Kata shim コンポーネントを経由します。 その後、OPA と連携するエージェントは、独自の API へのすべての呼び出しに対してポリシーを適用します。

このポリシーは、TCB の一部ではないコンポーネントを使用して提供されるため、最初はこのポリシーは信頼されません。 ポリシーの信頼性は、次のセクションで説明するように、リモート構成証明を使用して確立する必要があります。

ポリシー ドキュメントで信頼を確立する

ポッド CVM を作成する前に、Kata shim はポリシー ドキュメントの SHA256 ハッシュを計算し、そのハッシュ値を T Enterprise Edition にアタッチします。 このアクションにより、ポリシーの内容と CVM の間に強力なバインディングが作成されます。 この T Enterprise Edition フィールドは、CVM 内で実行されたソフトウェアまたはその外部で後で変更することはできません。

ポリシーを受信すると、エージェントはポリシーのハッシュが不変の T Enterprise Edition フィールドと一致することを確認します。 エージェントは、ハッシュの不一致を検出した場合、受信ポリシーを拒否します。

機密情報を処理する前に、ワークロードはリモート構成証明の手順を実行して、T Enterprise Edition、OS、エージェント、OPA、ルート ファイル システムのバージョンの予想されるバージョンを使用してワークロードが実行されていることを証明書利用者に証明する必要があります。 構成証明は、AMD Standard Edition V-SNP ハードウェアから署名された構成証明証拠を取得する CVM 内で実行されているコンテナーに実装されます。 構成証明証拠のフィールドの 1 つは、前に説明したポリシー ハッシュ T Enterprise Edition フィールドです。 そのため、構成証明サービスは、このフィールドの値とポッド ポリシーの予想されるハッシュを比較することで、ポリシーの整合性を確認できます。

ポリシーの適用

Kata エージェントは、ポリシーの適用を担当します。 Microsoft は、各エージェント ttrpc API 呼び出しのポリシーのチェックを担当するエージェント コードを Kata および CoCo コミュニティに提供しました。 API に対応するアクションを実行する前に、エージェントは OPA REST API を使用して、ポリシー ルールとデータが呼び出しを許可またはブロックするかどうかをチェックします。

次のステップ

AKS に機密コンテナーをデプロイする