適用於 Azure Kubernetes Service 上機密容器的安全性原則

如機密運算聯盟 (CCC) 所述，「機密運算是藉由在硬體型、受信任執行環境 (TEE) 中執行計算來保護使用中的資料。」AKS 機密容器的設計目的，是保護使用中的 Kubernetes Pod 資料避免來自外部未經授權的存取。 每個 Pod 都會在受 AMD SEV-SNP TEE 保護的公用程式 VM (UVM) 中執行，方法是加密使用中的資料，並防止主機操作系統 (OS) 存取資料。 Microsoft 工程師會與機密容器 (CoCo) 和 Kata Containers 開放原始碼社群合作設計和實作機密容器。

安全性原則概觀

Kata Containers 系統架構的主要元件之一是 Kata 代理程式。 使用 Kata 容器來實作機密容器時，代理程式會在硬體型 TEE 內執行，因此是 Pod 的信任運算基底 (TCB) 的一部分。 如下圖所示，Kata 代理程式提供了一組 ttrpc API，允許 TEE 以外的系統元件建立和管理機密型 Kubernetes Pod。 這些其他元件 (例如，Kata Shim) 不是 Pod 的 TCB 的一部分。 因此，代理程式必須保護自己免受潛在錯誤或惡意 API 呼叫的影響。

在 AKS 機密容器中，Kata 代理程式 API 自我保護是使用機密 Pod 擁有者指定的安全性原則 (也稱為 Kata 代理程式原則) 加以實作。 原則文件包含對應至每個 Pod 的規則和資料，使用業界標準 Rego 原則語言。 強制執行公用程式 VM (UVM) 內的原則是使用開放式原則代理程式 (OPA) (即雲端原生運算基金會 (CNCF) 的研究生專案) 來實作。

原則內容

安全性原則描述了對代理程式的 ttrpc API 的所有呼叫 (以及這些 API 呼叫的參數)，這些呼叫預期用於建立和管理機密 Pod。 每個 Pod 的原則文件都是使用 Rego 語言的文字檔。 原則文件分為三個高階部分。

資料

原則資料專屬於每個 Pod。 例如，它包含：

• 預計會在 Pod 中建立的容器清單。
• 預設會被原則封鎖的 API 清單 (基於機密性原因)。

Pod 中每個容器的原則文件中所包含的資料範例：

• 映像完整性資訊。
• 在容器中執行的命令。
• 記憶體磁碟區和掛接。
• 執行安全性內容。 例如，根檔案系統是否為唯讀？
• 此程序是否允許取得新的使用權限？
• 環境變數。
• Open Container Initiative (OCI) 容器執行階段組態中的其他欄位。

規則

以 Rego 格式指定的原則規則，會針對公用程式 VM (UVM) 外部的每個 Kata 代理程式 API 呼叫，由 OPA 執行。 代理程式會向 OPA 提供所有 API 輸入，而 OPA 會使用規則來檢查輸入是否與原則資料一致。 如果原則規則和資料不允許 API 輸入，代理程式會傳回「原則封鎖」錯誤訊息來拒絕 API 呼叫。 以下是一些規則範例：

• 每個容器層都會以唯讀 virtio 區塊 裝置公開至公用程式 VM (UVM)。 這些區塊裝置的完整性會使用 Linux 核心的 dm-verity 技術加以保護。 dm-verity 雜湊樹狀結構的預期根值會包含在原則資料中，並由原則規則在執行階段進行驗證。
• 當偵測到未預期的命令列、記憶體掛接、執行安全性內容或環境變數時，規則會拒絕建立容器。

根據預設，原則規則適用於所有 Pod。 genpolicy 工具會產生原則資料，並且專屬於每個 Pod。

預設值

當使用原則資料和 API 輸入作為參數評估 Rego 規則時，OPA 會嘗試尋找至少一組規則，根據輸入資料傳回 true 值。 如果規則未回傳 true，OPA 會向代理程式傳回該 API 的預設值。 原則中的預設值範例：

• default CreateContainerRequest := false – 表示拒絕任何 CreateContainer API 呼叫，除非一組原則規則明確允許該呼叫。

• default GuestDetailsRequest := true – 表示一律允許從 TEE 外部對 GuestDetails API 進行呼叫，因為此 API 傳回的資料對於客戶工作負載的機密性並不敏感。

將原則傳送至 Kata 代理程式

所有 AKS 機密容器公用程式 VM (UVM) 都會使用公用程式 VM (UVM) 根檔案系統中包含的一般預設原則啟動。 因此，必須在執行階段將符合實際客戶工作負載的原則提供給代理程式。 原則文字會內嵌在 YAML 資訊清單檔中，如先前所述，並在公用程式 VM (UVM) 初始化期間，以這種方式提供給代理程式。 原則註釋會透過 AKS 機密容器系統的 kubelet、containerd 和 Kata shim 元件進行傳輸。 然後，與 OPA 一起運作的代理程式會針對它自己的 API 的所有呼叫強制執行原則。

原則會使用不屬於 TCB 的元件來提供，因此一開始該原則不受信任。 原則的可信度必須透過遠程證明來建立，如下一節所述。

在原則文件中建立信任

建立公用程式 VM (UVM) 之前，Kata 填充碼會計算原則文件的 SHA256 雜湊，並將該雜湊值附加至 TEE。 該動作會在原則的內容與公用程式 VM (UVM) 之間建立強式繫結。 公用程式 VM (UVM) 內部或外部執行的軟體之後無法修改此 TEE 欄位。

收到原則之後，代理程式會驗證原則的雜湊值與不可變的 TEE 欄位是否相符。 如果代理程式偵測到雜湊值不相符，代理程式就會拒絕傳入的原則。

在處理敏感性資訊之前，您的工作負載必須執行遠端證明步驟，以向任何信賴憑證者證明工作負載是使用預期版本的 TEE、OS、代理程式、OPA 和根檔案系統版本執行的。 證明是在公用程式 VM (UVM) 內執行的容器中實作，該 UVM 會從 AMD SEV-SNP 硬體取得已簽署的證明辨識項。 證明辨識項的其中一個欄位，是稍早所述的原則雜湊 TEE 欄位。 因此，證明服務可以透過將該欄位的值與 Pod 原則的預期雜湊值進行比較，來驗證原則的完整性。

強制執行原則

Kata 代理程式負責強制執行原則。 Microsoft 為 Kata 和 CoCo 社群貢獻了代理程式程式碼，負責檢查每個代理程式 ttrpc API 呼叫的原則。 在執行對應至 API 的動作之前，代理程式會使用 OPA REST API 來檢查原則規則和資料是否允許或封鎖呼叫。

下一步

在 AKS 上部署機密容器