4-基于 Kata 的機密容器在螞蟻的落地實踐-final.pdf

《4-基于 Kata 的機密容器在螞蟻的落地實踐-final.pdf》由會員分享，可在線閱讀，更多相關《4-基于 Kata 的機密容器在螞蟻的落地實踐-final.pdf（23頁珍藏版）》請在三個皮匠報告上搜索。

1、基于 Kata 的機密容器(CoCo)在螞蟻的落地實踐李亞南螞蟻集團 高級軟件開發工程師Kata Containers Maintainer目錄 CoCo 與 Kata CoCo 在螞蟻的應用與實踐 問題探討CoCo 與 Kata什么是什么是 KataKata 和和 CoCoCoCoKataKata 與與 CoCoCoCo 的的差異差異CoCoCoCo 與與 KataKata 的依賴關系的依賴關系什么是 Kata Containers OpenInfra 基金會的頂級開源項目，旨在解決傳統容器技術中的安全性和隔離性問題。它將容器的輕量性與虛擬機的安全性完美結合，為云原生計算提供了一種新的運行時

2、解決方案。要解決的關鍵問題：1.容器安全隔離的脆弱性傳統容器共享宿主機內核，安全邊界模糊。容器逃逸攻擊風險較高。多租戶環境中隔離不充分。2.性能與安全的矛盾虛擬機安全但資源開銷大。容器輕量但隔離性弱。需要在安全性和性能間找平衡。核心技術架構：1.多個容器運行在獨立的輕量級虛擬機中2.利用硬件虛擬化技術（如VT-X/AMD-V、VT-d等）提供強隔離3.保持與標準 OCI 容器的兼容性，積極擁抱 Kubernetes 生態金融交易，醫療數據處理，云原生敏感計算等什么是 Confidential Containers(CoCo)CNCF 沙箱項目，于2022年正式加入 CNCF 生態。旨在通過硬件

3、級可信執行環境（Trusted Execution Environment,TEE）為容器提供端到端的數據機密性和完整性保護。解決的關鍵問題：云計算環境中數據在使用期間的脆弱性：傳統云計算中數據易遭受未授權訪問。云服務提供商可能獲取敏感數據。多租戶環境中的數據隔離困難。用戶對敏感工作負載的安全顧慮：金融、醫療等高度敏感的計算場景?？缭坪投嘣骗h境的數據保護。防范內部攻擊和潛在的基礎設施風險。核心技術架構基于運行時 Kata Containers:透明地為容器提供安全隔離環境。無需修改應用程序代碼。符合 OCI 容器標準，并擁抱 Kubernetes。硬件可信執行環境：利用 Intel TDX、A

4、MD SEV-SNP 等硬件安全技術。創建密封的計算環境。數據在處理過程中完全加密。CoCo 與 Kata 的差異維度Kata ContainersConfidential Containers可信主體宿主機可信（防御容器逃逸）宿主機不可信+防護客戶機數據與計算機密性技術基礎硬件虛擬化技術 KVM集成 TEE 硬件、遠程證明、存儲加密等全棧方案解決問題傳統容器在隔離性和安全性云環境中數據機密性和完整性，數據可用不可見的問題。KVMKVM+TEE(TDX/SEV-SNP等）CoCoCoCo 實際上是基于實際上是基于 Kata ContainersKata Containers 構建的機密計算解決

5、方案，兩者存在緊密的技術依賴關系。構建的機密計算解決方案，兩者存在緊密的技術依賴關系。CoCoCoCo 以以 Kata ContainersKata Containers 為運行時基座，通過擴展為運行時基座，通過擴展 TEE TEE 硬件支持、端到端加密以及相關度量等全硬件支持、端到端加密以及相關度量等全棧安全加固技術，實現云原生機密計算。棧安全加固技術，實現云原生機密計算。兩者協同解決從虛擬化隔離到數據隱私的全生命周期防護。兩者協同解決從虛擬化隔離到數據隱私的全生命周期防護。CoCo 與 Kata 的關系CoCo 在螞蟻的應用與實踐在云環境中運行在云環境中運行 Apache SparkApa

6、che Spark 業務業務利用利用 CoCoCoCo 實現實現 SparkSpark 機密大數據分析機密大數據分析云環境運行 Apache Spark 業務需求（在云環境運行 Spark 任務）：在機器學習訓練或身份匹配場景中，往往希望通過在 Kubernetes 環境中以 Pod 形式運行 Spark 作業，并能根據作業資源需求以及數據大小進行動態調度和擴縮容，以支持分布式數據處理。在 K8S 中運行 Spark 作業的好處：（1）資源的集中管理和動態調度，提高集群整體資源利用率。（2）統一運維方式，提升運維效率，降低管理復雜度。（3）通過容器鏡像標準化部署，解決不同 Spark 版本間的

7、兼容性問題，提高跨平臺部署能力。（4）具備動態擴展計算資源的能力，能根據作業需求以及數據大小進行動態調度和擴縮容。云計算環境中大數據安全面臨的復雜挑戰和威脅！大數據安全Integrity完整性Availability 可用性Confidentiality 機密性運行在K8S環境中的機密大數據平臺需要實現 CIA 安全模型：（1）機密性 Confidentiality信息安全的基本。需保證數據真實內容只能被授權的主體訪問，使用加密技術來完成。（2）完整性 Integrity信息安全的重要組成部分。完整性保證數據來源的完整性和數據內容的完整性，確保數據只被授權的主體進行修改。（3）可用性 Avai

8、lability可用性指系統能夠保持正常運行，更多涉及數據、服務或平臺的可操作性。大數據安全/威脅模型機密數據安全威脅：（1）非授權用戶訪問：非授權用戶/攻擊者通過攻擊或偽裝等方式，獲取大數據集群的訪問權限進行非授權的操作或破壞。（2）內在用戶威脅：來自內部正常用戶和業務的威脅和攻擊，攻擊者往往具有系統訪問權限，能使用合法憑證登錄，且能通過一系列安全審查，并執行特定攻擊。（3）數據流轉威脅：數據在存儲，傳輸和處理過程中數據沒有進行加密和驗證，無法防護未授權用戶訪問或篡改隱私/敏感數據。利用 CoCo 實現 Spark 機密大數據分析需求：確保數據集從原始可信源到云環境，始終保持加密狀態并在 T

9、EE 中進行數據處理。機密容器引入了遠程證明和安全密鑰釋放的功能，可以應用到 Spark 作業，以處理僅在可信執行環境(TEE)中授權釋放密鑰的加密數據集?；?CoCo 實現的機密大數據分析：在云環境中使用持續加密的數據集處理敏感的監管數據時：（1）K8S 集群僅將 Spark 作業調度到經過證明的可信執行環境 TEE。（2）存儲中的機密數據始終使用客戶密鑰加密。必須先申請密鑰。（3）客戶密鑰僅釋放到 TEE 中，在內部利用客戶密鑰進行解密。（4）加密數據在可信執行環境（TEE）內部被解密并以明文形式可用。（5）在 TEE 中處理完數據后，將結果以密文返回。HyperEnclave螞蟻開源的

10、一個開放的、跨平臺的TEE。它對于硬件的依賴很小，只需要平臺支持 KVM 虛擬化擴展，就可以創建隔離的可信執行環境。https:/ runtime-rs/Kata-AgentMeasured BootRemote snapshotternydusnydus snapshottersnapshotter withwith Proxy modeProxy modehttps:/ CoCo 的云原生機密大數據分析Host OS 信任根（TPM）1.啟動度量：固件UEFIBootLoaderKernel+initramfsKernel cmdline 逐級度量，擴展至 TPM PCR 寄存器。2.安全

11、隔離：initramfs 加載 DriverHyperEnclave 接管控制權Host OS 降級為非特權模式（操作受 HyperEnclave 審計）。CVM 信任根（HyperEnclave）1.啟動驗證：度量 td-shimGuest KernelKernel cmdline，確保組件完整性。2.持久化保護：rootfs 分區通過 dm-verity 機制校驗（root hash 預置在 kernel cmdline），信任鏈延伸至系統服務。最終保障全鏈路組件（Host OS+CVM）均通過完整性認證，業務應用運行于可信環境?？尚耪J證CVM 啟動度量1.啟動階段測量（Measured

12、Boot）固件層測量：硬件 TEE（如 Intel TDX/AMD SEV）在啟動時測量關鍵組件（固件、內核、內核命令行等）。內核命令行參數（如 cc_rootfs_verity.hash）被納入測量范圍，記錄根哈希值。證據生成：測量結果（哈希值）存儲在 TEE 的安全寄存器中，作為遠程證明（Remote Attestation）的可信證據。2.基于 dm-verity 的輕量化測量內核級完整性保護：dmdm-verityverity：塊設備級只讀保護，實時校驗數據塊哈希樹。內核命令行參數內核命令行參數嵌入根哈希（cc_rootfs_verity.hash），作為測量證據。集成流程：initr

13、amfsinitramfs 嵌入工具嵌入工具：靜態編譯 veritysetup 和初始化腳本 init.sh。通過 CONFIG_INITRAMFS_SOURCE 打包至內核鏡像，隨內核一同測量。哈希樹構建：啟動鏡像（rootfs）被劃分為數據塊，逐層生成哈希樹。根哈希（Root Hash）存儲于內核命令行參數中（如 cc_rootfs_verity.hash=xxx）。運行時驗證：掛載階段掛載階段：initramfs 中的腳本通過 veritysetup 掛載 dm-verity 設備，校驗根哈希。訪問階段訪問階段：每次讀取數據塊時，內核通過哈希樹逐層驗證其完整性。Passport Mode

14、l：護照模型，類似現實中的護照驗證，預先頒發認證令牌（如數字證書），后續通信依賴該令牌。遠程證明（RA/KMS）特點：對業務侵入性低，不感知RA的過程。低延時，性能開銷低?？蓪嵺`性強。共享文件系統virtiofsvirtiofs 破壞 TEE 安全邊界，使主機成為不可控攻擊面：數據泄露風險解密數據暴露：通過 virtiofs 共享目錄，主機可直接訪問客戶機內解密的敏感數據。篡改攻擊面運行時篡改：惡意主機可修改共享掛載的 rootfs，注入惡意代碼或邏輯，影響容器行為（即使鏡像已簽名或加密）。Host/Guest 之間高效的文件共享方案定位與目標由紅帽于2018年提出，專為 Kata Conta

15、iners 等容器場景設計，旨在通過共享Host目錄樹實現多 Guest 間文件系統的高效、一致、安全共享。工作原理virtiofs 通過 virtio 傳輸層實現 FUSE 協議，在 Host 端與 Guest 端建立通信后，利用 DAX 技術將 Host 文件直接映射至VMM 進程內存空間，使多個 Guest 通過共享內存訪問同一份數據，繞過 Guest Page Cache 以實現零拷貝、內存高效共享與跨虛擬機強一致性。禁用共享文件系統影響維度影響描述容器啟動速度無法通過共享目錄傳遞鏡像/配置，鏡像在容器創建流程中拉取，需依賴塊設備或臨時存儲，啟動延遲增加文件共享能力主機與客戶機間動態文

16、件共享受限，以文件共享方式的掛載被禁止持久化存儲兼容性依賴共享文件系統的 K8S PV/PVC 需適配塊存儲方案（如 virtio-blk 直通）禁用共享文件系統確實能減少攻擊面，加固安全邊界。但卻也引入新的挑戰：鏡像無法共享每個容器都需要重新拉取容器鏡像，尤其pod重建，都需要重新拉取禁用共享文件系統的核心目標是 切斷主機對客戶機存儲的直接訪問，以達到：防止敏感數據通過共享路徑泄露。阻止主機篡改容器運行時環境。減少對不可信主機配置的依賴，提升 TEE 邊界安全性。Guest Image Pull容器鏡像完整性與機密性remote snapshotter 負責將鏡像相關信息打包成 Image

17、Info 并轉換成 OCI Runtime Spec MountKata runtime 負責解析 Mount/Options 并生成生成 virtual volume 將信息傳遞給 kata-agentKata-Agent 與 image-rs 協作完成鏡像拉取加密存儲目標：低成本可信存儲，替代內存存儲，擴展可信邊界到存儲層實現：（1）客戶機直接掛載存儲設備，避免數據泄漏，僅TEE可解密敏感數據并訪問明文（2）借助于Linux系統中dm-crypt/dm-integrity來完成數據加解密/數據完整性（1）CSI驅動負責動態分配塊設備卷（2）Kata runtime使用virtio-blk將

18、設備插入虛擬機（3）Kata-agent 初始化存儲設備，并從AA獲取密鑰，解密數據數據機密性TEE Isolation+Block device with dm-crypt數據完整性Block device with dm-integrity密鑰管理遠程證明（AA/KBS）獲取解密密鑰其他存儲臨時存儲 emptyDir：采用virtio-blk直通文件存儲位置：emptyDir 的存儲空間位于 Pod 調度的節點本地。例如/var/lib/kubelet/pods/volumes/kubernetes.ioempty-dir）。生命周期：創建：當 Pod 被調度到節點時，emptyDir 卷

19、會被自動創建。銷毀：當 Pod 被刪除時，卷及其數據會被徹底清理。數據共享：同一 Pod 內的多個容器可以共享 emptyDir Volume。典型場景典型場景臨時文件存儲：例如緩存文件、中間計算結果。容器間共享數據：如 Sidecar 容器與主容器共享日志或配置。節點本地存儲 hostPath：在 CoCo 場景下，這種情況是被禁止的。存儲位置：hostPath 直接掛載節點上的指定目錄或文件（例如/data/app）。生命周期：持久性：數據與節點本地存儲的生命周期一致，即使 Pod 被刪除，數據仍保留在節點。依賴節點：若 Pod 被重新調度到其他節點，將無法訪問原節點的 hostPath

20、數據。數據共享：不同 Pod（調度到同一節點時）可以通過掛載相同 hostPath 共享數據。冷插 GPU 設備 Outer CDI(Containerd)負責把硬件設備以VFIO設備的形式映射到OCI Spec，以完成設備直通到Guest中。Inner CDI(Kata-Agent)負責把GPU設備及相關的Mounts，Envs，Hooks文件映射到映射到OCI Spec，以使得GPU設備正確暴露給容器。問題探討CoCo場景下，如何高效運維而不失安全性？如何減少Pod啟動速度，降低容器鏡像拉取時延？是否可以直接Host Pull image？正確區分文件或內容完整性/機密性類型？TEE 自證清白？謝謝