Inclavare Containers：雲原生機密計算的未來
簡介：本文為你詳細的梳理一次 Inclavare Containers 專案的發展脈絡，解讀它的核心思想和創新技術。
不過，如果你對機密計算領域不太關注，可能對 Inclavare Containers 還沒有做過太深入的瞭解。彆著急，本文為你詳細的梳理一次 Inclavare Containers 專案的發展脈絡，解讀它的核心思想和創新技術。
首先，什麼是 Inclavare Containers？
一言以蔽之，Inclavare Containers 是業界首個面向機密計算場景的開源容器執行時。可是，什麼是機密計算呢？Inclavare Containers 跟機密計算又是什麼關係？它能幫助我們解決什麼問題？
資料安全與機密計算
資料在整個生命週期有三種狀態：At-Rest（靜態）、In-Transit（傳輸中）和 In-Use（使用中）。
- At-Rest 狀態下，一般會把資料存放在硬碟、快閃記憶體或其他的儲存裝置中。保護 At-Rest 狀態的資料有很多方法，比如對檔案加密後再存放或者對儲存裝置加密。
- In-Transit 是指通過公網或私網把資料從一個地方傳輸到其他地方，使用者可以在傳輸之前對檔案加密或者採用安全的傳輸協議保證資料在傳輸中的安全，比如HTTPS、SSL、TLS、FTPS 等。
- In-Use 是指正在使用的資料。即便資料在傳輸過程中是被加密的，但只有把資料解密後才能進行計算和使用。也就意味著，如果資料在使用時沒有被保護的話，仍然有資料洩露和被篡改的風險。
在這個世界上，我們不斷地儲存、使用和共享各種敏感資料：從信用卡資料到病歷，從防火牆配置到地理位置資料。保護處於所有狀態中的敏感資料比以往任何時候都更為重要。如今被廣泛使用的加密技術可以用來提供資料機密性（防止未經授權的訪問）和資料完整性（防止或檢測未經授權的修改），但目前這些技術主要被用於保護傳輸中和靜止狀態的資料，目前對資料的第三個狀態“使用中”提供安全防護的技術仍舊屬於新的前沿領域。
機密計算指使用基於硬體的可信執行環境（Trusted Execution Environment，TEE）對使用中的資料提供保護
機密計算的核心功能有：
- 保護 In-Use 資料的機密性。未經授權的實體（主機上的應用程式、主機作業系統和Hypervisor、系統管理員或對硬體具有物理訪問許可權的任何其他人。）無法檢視在TEE中使用的資料，記憶體中的資料是被加密的，即便被攻擊者竊取到記憶體資料也不會洩露資料。
- 保護 In-Use 資料的完整性。防止未經授權的實體篡改正在處理中的資料，度量值保證了資料和程式碼的完整性，使用中有任何資料或程式碼的改動都會引起度量值的變化。
- 可證明性。通常 TEE 可以提供其起源和當前狀態的證據或度量值，以便讓另一方進行驗證，並決定是否信任 TEE 中執行的程式碼。最重要的是，此類證據是由硬體簽名，並且製造商能夠提供證明，因此驗證證據的一方就可以在一定程度上保證證據是可靠的，而不是由惡意軟體或其他未經授權的實體生成的。
機密計算的現狀與困境
業界內的諸多廠商就已經開始關注並投入到機密計算中。各大晶片廠家和雲服務提供商（Cloud Service Provider，簡稱 CSP）都在機密計算領域投入研發資源，並組建了“機密計算聯盟”。該聯盟專門針對雲服務及硬體生態，致力於保護計算時的資料安全。
目前支援TEE的硬體平臺主要有 3 個：Intel® SGX、ARM TrustZone 和 AMD SEV，他們有不同的應用場景和實現方式。
1、ARM TrustZone 把硬體資源分為安全世界和非安全世界兩部分，所有需要保密的操作在安全世界執行，其餘操作在非安全世界執行，安全世界和非安全世界通過一個名為 Monitor Mode 的模式進行轉換。典型的應用場景有移動支付、數字錢包等。
2、AMD 利用 SEV（AMD Secure Encrypted Virtualizationn），SME（AMD Secure Memory Encryption）和SEV-ES（Secure Encrypted Virtualization-Encrypted State）等技術實現虛擬機器的 Guest 記憶體加密和安全隔離。
3、Intel® SGX 是 Intel 提供的一組指令，用於提高應用的程式碼和資料的安全性。Intel® SGX 程式由不可信程式碼和可信 Enclave 組成，敏感的程式碼和資料放入到 Enclave 中。Intel® SGX 指令在一個特定的加密記憶體區域（EPC）中建立和執行 Enclave，該區域由開發者定義受限的入口和出口函式，有效防止資料洩露。
目前機密計算目前正處於百花齊發和百家爭鳴的階段，市場和商業化潛力非常巨大。但機密計算在雲原生場景中還有一些不足：
1、目前提供的技術的使用和開發門檻高。以開發 Intel® SGX 應用用例，使用者需要學習 Intel® SGX 開發技能並對業務進行改造。相比傳統開發方式，其使用和開發門檻很高，令很多開發者望而生畏。2、機密計算容器化和對接 Kubernetes 的成本和複雜度高。越來越多的使用者開始擁抱雲原生，即便使用者掌握了機密計算的開發技能，讓機密計算應用跑在容器裡或者跑在 Kubernetes 裡還要克服很多問題。比如如何在容器內載入 SGX 驅動，如何為容器合理分配 EPC 記憶體等。
3、服務提供商提供的技術方案相對單一。現在很多服務提供商都提供了機密計算的技術方案，但方案總體來說比較單一，並不能完全滿足使用者上雲的需求。 比如 Google 的 Asylo 和 Azure 的 OpenEnclave，他們是在 Intel® SGX SDK 的基礎上做了封裝，以降低使用者使用機密計算技術的成本。但這仍然需要使用者掌握 Intel® SGX 的開發技能，對使用者而言仍然是有學習門檻的。 再比如 Occlum、GraphaneSGX 等 LibOS 技術，他們的目的是讓使用者在不改動程式碼或做改動很少的程式碼就能讓應用執行在 Enclave中。對使用者而言不必再去學習複雜的機密計算的開發技術，但這只是解決了使用者開發的問題，但仍然沒有解決在容器中執行機密計算應用的問題。
總之，目前已有的機密計算技術方案存在以上困境，不能夠完全滿足使用者不同場景的安全需求。
為了解決以上問題，Inclavare Containers 提供了首個面向機密計算場景的開源容器執行時，把機密計算技術和容器技術完美地結合在一起，其價值可概括為三點：
- 抹平機密計算的高使用門檻，為使用者提供與普通容器一致的使用體感。
- 基於處理器提供的多種硬體安全技術，提供對多種 Enclave 形態的支援，為使用者在安全和成本之間提供更多的選擇和靈活性。
- 加速基於零信任模型的機密計算雲基礎設施的構建。
Inclavare Containers：雲原生機密計算的未來
Inclavare Containers 支援機密應用基於硬體的 TEE 被透明地容器化。帶來了以下的好處：
- 輕鬆將機密應用帶入雲原生。
- 在基於硬體的 TEE 中執行修改/未修改的應用程式（取決於 Enclave Runtime）。
- 為應用的資料和程式碼提供機密性、完整性和可證明性。
如下圖所示，Inclavare Containers 中包含多個元件，這些元件可以利用基於硬體支援的 Enclave 技術使可信應用執行在容器中。包含的元件有 rune、shim-rune、Enclave Runtime等。
- rune：rune 是一個命令列工具，用於根據 OCI 規範在容器中生成和執行 Enclave。rune 是在 runc 程式碼基礎上開發的，既可以執行普通 runc 容器也可以執行 Enclave 容器；rune已經寫入 OCI 執行時實現列表：
- shim-rune：為容器執行時 rune 提供的 shim，主要負責管理容器的生命週期、把普通映象轉換成 TEE 映象；管理容器的生命週期，與 rune 配合完成容器的建立、啟動、停止、刪除等操作。
- Enclave Runtime：負責在 Enclave 內載入和執行受信任和受保護的應用程式。rune 和 Enclave Runtime 之間的介面是 Enclave Runtime PAL API，它允許通過定義良好的函式介面來呼叫 Enclave Runtime。機密計算應用通過這個介面與雲原生生態系統進行互動。
一類典型的 Enclave Runtime 實現基於庫作業系統。目前，推薦的與 rune 互動的 Enclave Runtime 是 Occlum，這是一種記憶體安全、多程序 Libos。另一類典型的 Enclave Runtime是帶有 Intel® SGX WebAssembly Micro Runtime (WAMR)，這是一個佔用空間很小的獨立 WebAssembly (WASM) 執行時，包括一個 VM 核心、一個應用程式框架和一個 WASM 應用程式的動態管理。
此外，您可以使用您喜歡的任何程式語言和 SDK（例如英特爾 SGX SDK）編寫自己的Enclave Runtime，只要它實現了 Enclave Runtime PAL API。
1、將 Intel® SGX 技術與成熟的容器生態結合，將使用者的敏感應用以 Enclave 容器的形式部署和執行；Inclavare Contianers 的目標是希望能夠無縫執行使用者製作的普通容器映象，這將允許使用者在製作映象的過程中，無需瞭解機密技術所帶來的複雜性，並保持與普通容器相同的使用體感。
2、Intel® SGX 技術提供的保護粒度是應用而不是系統，在提供很高的安全防護手段的同時，也帶來了一些程式設計約束，比如在 SGX enclave 中無法執行 syscall 指令；因此我們引入了 LibOS 技術，用於改善上述的軟體相容性問題，避免開發者在向 Intel® SGX Enclave 移植軟體的過程中，去做複雜的軟體適配工作。然後，雖然各個 LibOS 都在努力提升對系統呼叫的支援數量，但這終究難以企及原生 Linux 系統的相容性，並且即使真的達成了這個目標，攻擊面過大的缺點又會暴露出來。因此，Inclavare Containers 通過支援 Java 等語言Runtime 的方式，來補全和提升 Enclave 容器的泛用性，而不是將 Enclave 容器的泛用性繫結在“提升對系統呼叫的支援數量” 這一單一的相容性維度上；此外，提供對語言 Runtime 的支援，也能將像 Java 這樣繁榮的語言生態引入到機密計算的場景中，以豐富機密計算應用的種類和數量。
3、通過定義通用的 Enclave Runtime PAL API 來接入更多型別的 Enclave Runtime，比如 LibOS 就是一種 Enclave Runtime 形態；設計這層 API 的目標是為了繁榮 Enclave Runtime 生態，允許更多的 Enclave Runtime 通過對接 Inclavare Containers 上到雲原生場景中，同時給使用者提供更多的技術選擇。
靈活的機密容器部署方式
Docker 叢集
對於普通使用者來說，如何執行一個機密容器是一個非常困難的事情，您需要掌握機密計算領域的專業知識，並按照 SGX 應用開發規範開發和構建映象。而Inclavare Containers 設計並實現了符合 OCI 執行時規範的新型 OCI 執行時 rune，以便與現有的雲原生生態系統保持一致，實現了機密容器形態。不僅可以幫您省去這些複雜過程，還可以使您像普通容器一樣使用機密容器。
Inclavare Containers 可以與 dockerd 整合。 具體來說，您需要在構建容器映象時安裝首選的 Enclave Runtime，並在您的機器的docker 配置檔案中新增 rune 的相關配置，例如，/etc/docker/daemon.json。
{
"runtimes": {
"rune": {
"path": "/usr/local/bin/rune",
"runtimeArgs": []
}
}
}
然後重啟 docker 服務即可。
1、使用者開發機密應用。使用者不需要掌握機密計算的知識，Occlum 提供了工具可以把普通應用轉換為機密應用。需要注意的是：Occlum 有一些使用限制，詳情請查閱文件：
2、基於 Occlum 生成的檔案構建映象，構建成功後推入映象倉庫。3、通過標準 docker 拉起容器映象，最終使用 rune 執行時啟動 Enclave 容器並執行 Occlum 和 Enclave 應用。
Kubernetes 叢集
雖然 Docker 叢集中能執行 Enclave 容器，但還有一些不足：
- 無法動態管理和排程 EPC。
- 容器編排能力弱，沒有 Kubernetes 面向終態設計的容器管理方式。
Inclavare Containers 已經新增到 containerd 的採用者列表中：
[plugins.cri.containerd]
...
[plugins.cri.containerd.runtimes.rune]
runtime_type = "io.containerd.rune.v2"
然後重啟 containerd 即可。
如上圖所示，在雲上 Kubernetes 機密計算叢集中建立 Occlum 機密容器的工作流程如下：
1、kubelet 向containerd 發起 CRI（Container Runtime Interface）請求，比如請求建立一個 Pod。
2、Containerd 中有一個 cri-containerd 的外掛實現了 CRI 介面，Containerd 接收到請求後，把請求轉給 shim-rune。
3、shim-rune 既可以建立 runc 容器也可以建立 rune 容器。在建立 runc 和 rune 容器的處理流程也有差異：
- 建立 runc 容器：與建立普通 runc 容器過程完全一樣，比如 Pod 的 pause 容器就是 runc 容器。
- 建立 rune 容器：利用 LibOS 把普通映象轉換成 TEE 映象，rune 會在容器內建立 Enclave 並把應用執行在 Enclave 中。
4、為每個容器分別建立一個 rune 程序，該程序負責來建立容器，建立 runc 容器和 Enclave 容器的流程是不同的：
- 建立 runc 容器：與 runc 建立 runc 容器的流程完全一樣。
- 建立 Enclave 容器：每種 Enclave Runtime 都會提供一個實現了 Enclave Runtime PAL API 的動態庫so 。rune 先在 Host 上載入 liberpal.so，然後按照 runc 的方式建立容器，並在容器內啟動 1 號程序 init-runelet ，init-runelet 接收到 rune 的請求後加載並建立 Enclave。Encalve 包含一般包含兩部分：LibOS 和 App/語言 Runtime。LibOS 是 Enclave Runtime 提供的用於支撐應用執行的作業系統庫，App/語言 Runtime 是應用本身，有的語言也會有語言 Runtime，比如執行 OpenJDK 11 應用需要 JVM。
5、rune 程序退出，並把 Enclave 容器內 1 號程序的父程序設定為 shim-rune。6、shim-rune 請求 rune 啟動 Enclave。至此一個可信應用就執行起來了。
K8s 叢集級遠端證明架構
為了進一步滿足“使用者敏感資料的安全性在傳輸鏈路上也能夠完全不再依賴雲廠商”這一安全需求，Inclavare Containers 設計了一套通用的和跨平臺的遠端證明架構 Enclave Attestation Architecture（簡稱 EAA）。EAA 以“關聯了帶有硬體可執行環境的遠端證明證據的 TLS 證書”為信任根，確保通訊各方的通訊通道的安全性完全是基於硬體可信執行環境的。
- Enclave-TLS
Enclave-TLS 增強了標準 TLS 以支援基於機密計算技術的異構硬體 TEE 之間的可信通訊，是一種支援異構硬體可執行環境的雙向傳輸層安全性協議 (Transport Layer Security，簡稱TLS）。通過使用 Enclave-TLS，即使是非硬體 TEE 平臺也可以通過經過認證的安全通道與硬體 TEE（例如 SGX Enclave）通訊以傳輸敏感資訊。總的來說，TCB 的邊界從執行環境擴充套件到使用 Enclave-TLS 的網路傳輸。此外，Enclave-TLS 有一個可擴充套件的模型來支援各種硬體 TEE。
- 機密容器
機密容器扮演證明者的角色。響應來自 Inclavared 的請求，並返回機密容器的attestation evidence（mrenclave 值和 mrsigner 值）。
- Inclavared
Inclavared 負責轉發下游的機密容器和上游的客戶端驗證者程式 Shelter 之間的流量，通訊過程受到經過證明的 Enclave-TLS 通道的保護。
- Shelter
Shelter 作為部署在雲下的遠端證明驗證者，記錄 Enclave 執行時的啟動度量，然後基於 Enclave-TLS 建立可信通道 Inclavared 進行通訊。最後，Shelter 對Enclave 執行時的度量值進行驗證，以便租戶能夠明確知道他們的工作負載是否在真正的 TEE 環境中載入。
具體的工作流程如下：
當用戶想驗證工作負載是否執行在可信平臺上時，可以啟動 Shelter 工具傳送驗證請求給 Inclavared。
1、當接收到 Shelter 的驗證請求之後，Inclavared 將請求傳送給機密容器，Inclavared 和機密容器分別產生帶有 SGX 遠端認證資訊的 TLS 證書。
2、Inclavared 和 Shelter 之間基於 Enclave-TLS 建立經過證明的安全通道。
3、Inclavared 與機密容器之間基於 Enclave-TLS 建立經過雙向認證的安全通道。
4、Inclavared 轉發機密容器提供的硬體可執行環境資訊和敏感資訊給 Shelter
5、Shelter 對 Enclave 執行時的度量值進行驗證，並返回驗證結果給使用者。
五大技術創新
Inclavare Containers 提供了相容 OCI Runtime 的容器執行時，使用者可根據需要在 Docker 叢集或者 Kubernetes 叢集中執行 Enclave 容器。通過 Enclave Runtime 抹去了使用者使用機密計算技術的門檻，在 Kubernetes 叢集中更是保持了與普通容器一致的使用體驗。通過 Encalve Runtime PAL API 可以提供多種 Runtime 實現，為使用者提供更多 Enclave 選擇，在安全和成本之間提供更多的選擇和靈活性。
Inclavare Containers 的技術創新主要體現在以下幾點：
1、實現了標準的應用 enclave 化技術。
- 將機密計算硬體技術（如Intel® SGX）與成熟的容器生態結合，相容 OCI Runtime 和 OCI 映象標準，實現了機密容器形態。使用者的敏感應用以機密容器的形式部署和執行，並保持與使用普通容器相同的使用體感。
2、基於Enclave-TLS、shelter、inclavared 設計了靈活可擴充套件的 K8s 叢集級遠端證明架構。
- 通過構建通用且跨平臺的遠端證明安全架構，能夠向用戶證明其敏感的工作負載是執行在真實可信的基於硬體的可信執行環境中的。
3、制定了通用的PAL API，規範化了enclave runtime 對接 Inclavare Containers 的介面，打造 Inclavare Containers 的生態。
- 通過標準的 API 規範來對接各種形態的 Enclave Runtime，在簡化特定的Enclave Runtime 對接雲原生生態的同時，也為使用者提供了更多的技術選擇。
4、構造基於零信任模型的機密計算叢集基礎設施。
- 移除對雲服務提供商的信任，Inclavare Containers 的安全威脅模型假設使用者無需信任雲服務提供商，即使用者工作負載的安全性不再依賴雲服務提供商控制的特權元件。
5、與 Kubernetes 生態無縫整合。
- Inclavare Containers 可以部署在任何公共雲 Kubernetes 平臺中，實現了統一的機密容器部署方式。
結語
作為業界首個面向機密計算場景的開源容器執行時，Inclavare Containers 為ACK-TEE（ACK-Trusted Execution Environment）提供了使用機密容器的最佳實踐。ACK-TEE 依託 Inclavare Containers，能夠無縫地執行使用者製作的機密容器映象，並保持與普通容器相同的使用體感。ACK-TEE 可被廣泛應用於各種隱私計算的場景，包括：區塊鏈、安全多方計算、金鑰管理、基因計算、金融安全、AI、資料租賃。
未來，Inclavare Containers將繼續為開源社群提供面向雲原生場景的機密計算容器技術、機密計算叢集技術和安全架構，併成為該領域的事實標準。在不斷深化實施零信任模型原則的同時，不斷提升開發者和使用者的使用體驗，並最終完全消除與執行普通容器在使用體感上的差別。同時，Inclavare Containers 將積極參與共建雲原生社群，深度聯手上下游夥伴一同推動雲原生安全技術不斷進步，為打造更安全的雲原生環境不懈努力。
本文為阿里雲原創內容，未經允許不得轉載。