10-機密計算在無服務器（Serverless）架構中的應用：機遇和挑戰 - 李磊劉艷松.pdf

《10-機密計算在無服務器（Serverless）架構中的應用：機遇和挑戰 - 李磊劉艷松.pdf》由會員分享，可在線閱讀，更多相關《10-機密計算在無服務器（Serverless）架構中的應用：機遇和挑戰 - 李磊劉艷松.pdf（24頁珍藏版）》請在三個皮匠報告上搜索。

1、機密計算在無服務器（Serverless）架構中的應用：機遇和挑戰中國移動云能力中心 容器服務團隊李磊劉艷松目錄Serverless和機密計算01性能評估03Knative+Confidential Containers02Content結論和挑戰04Serverless和機密計算Part 01Serverless架構 Serverless強調的是一種架構理念和服務模型，所謂的“無服務器”是對用戶而言的，本質并不是不需要服務器。Serverless架構允許用戶將主要精力集中在產品代碼的開發上，而將基礎設施建設、系統管理、應用構建以及部署等任務全部委托給第三方，也就是云供應商來負責管理。給用戶帶

2、來的核心價值：彈性伸縮：根據流量自動擴展或縮減資源 按需付費：用多少資源就花多少錢，不用為閑置資源來買單 簡化運維：省去資源管理的煩惱，快速迭代和部署應用安全方面的挑戰：業務數據的機密性 業務邏輯執行的完整性依賴云供應商提供的無服務器運行環境的安全性，同時需要信任云供應商機密計算（Confidential Computing）Confidential Computing Consortium 中的定義：Confidential Computing is the protection of data in use by performing computation in a hardware-b

3、ased,attested Trusted Execution Environment.主要成員：Trusted Execution Environment基本思想 在CUP和內存中單獨劃分一塊隔離區域，進行敏感數據相關的計算。通過基于硬件的加密保護，使得CPU的其它部分無法訪問這塊區域。TEE中的數據不能被TEE之外的任何代碼讀取和篡改。只有經過適當授權的代碼，才能夠在TEE內操作數據。對外僅提供經過授權的接口關鍵特征 Data confidentiality：未經授權的實體無法查看TEE中正在使用的數據 Data integrity：未經授權的實體無法篡改TEE中正在使用的數據 Code

4、integrity：未經授權的實體無法篡改運行在TEE中的代碼未經授權的實體可能包括：主機操作系統 hypervisor 系統管理員 服務提供商 基礎設施所有者 或者任何可以物理訪問硬件的人員可信計算基（TCB，Trusted Computing Base）可信計算基(TCB)是指構成提供安全環境的系統的所有硬件、固件和軟件組件 如果 TCB 內部有一個組件存在風險，那么可能會危及整個系統的安全 較低的TCB意味著其包含的組件更少，也就意味著更高的安全性采用機密計算技術，將云供應商及其提供的基礎設施排除在TCB之外，提升了云上應用的安全性機密容器（Confidential Containers

5、）CNCF 下的創新沙箱（Sandbox）項目，簡稱COCO 宗旨：將TEE和云原生結合起來，提供云原生的機密計算。設計目的：Remove cloud and infrastructure providers from the guest application Trusted Computing Base(TCB).從客戶應用TCB中移除云和基礎架構提供商。Integrate natively with the Kubernetes control plane.與 Kubernetes 控制平面進行原生集成。Provide an unmodified Kubernetes user and

6、developer experience.Kubernetes的使用和開發體驗不變。Deploy unmodified workloads.部署的工作負載無需修改。View Project WebsiteKnative+Confidential ContainersPart 02Knative+Kata將機密容器應用到Serverless架構Kata+COCOKnative+Kata+COCO環境搭建AMD Secure Encrypted Virtualization(SEV)TEE選擇：海光 China Secure Virtualization(CSV)Intel Software Gu

7、ard Extensions(SGX)/Trusted Domain Extensions(TDX)鯤鵬 TrustZone 基礎設施：海光C86 7380 CPU的裸金屬物理機 操作系統：BC-Linux v8.8(Anolis 8.8)with kernel 5.10.134-csv Kubernetes Version:v1.28。單節點集群。Attestation：simple-kbs(Simple Key Broker Server)頂層架構性能評估Part 03方案設計和測試結果基準（Baselines）runc container：在主機上運行container，用namespa

8、ce隔離。Kata VM：在普通虛擬機中運行container。COCO cVM：在使能了CSV的機密虛擬機中運行container。指標（Metrics）冷啟動（Cold Start）：指在創建 Knative Service 之后，首次發起請求并得到返回結果這一過程所花費的時間。熱啟動（Warm Start）：指在 Knative Service 縮容至零實例（Scale to Zero）后，再次發起請求并得到返回結果這一過程所花費的時間。方案設計和測試結果BaselineCold StartWarm Startrunc container5 s1 sKata VM7 s2 sCOCO c

9、VM18 s18 shttps:/ 在啟用 CSV 的條件下，通過 OVMF 啟動機密虛擬機比啟動普通虛擬機多花費 4 秒。在機密虛擬機內拉取容器鏡像（含簽名驗證或鏡像解密）的耗時是主機上拉取鏡像的 2.5 倍。024681012runcKata VMCOCO cVM啟動時間比較Start VMPull image熱啟動分析 熱啟動時間 冷啟動時間 原因：每次都需要創建新的機密虛擬機，然后重新拉取鏡像。結論和挑戰Part 04結論分析 ACM數字圖書館一篇研究論文結論基本一致 https:/dl.acm.org/doi/10.1145/3642977.3652097pod-schedullin

10、g耗時很少，差異不大runc和kata 冷熱啟動差異巨大（Image-pull）CoCo冷熱啟動差異不大（都很慢）cVM啟動耗時巨大結論分析內存分頁帶來時間花費2GB vs 128GB結論分析 Pod的啟動：沙盒（sandbox，pause）-拉取鏡像（image pull）-容器啟動（負載相關）kata運行時（runtime）：guest OS-VM啟動 OVMF(Open Virtual Machine Firmware)內存分頁（memory page）沙箱啟動優化 VMM優化-DragonballNydus容器鏡像按需下載，用戶不再需要下載完整鏡像就能啟動容器塊級別的鏡像數據去重，最大限度為用戶節省存儲資源鏡像只有最終可用的數據，不需要保存和下載過期數據端到端的數據一致性校驗，為用戶提供更好的數據保護兼容 OCI 分發標準和 artifacts 標準，開箱即可用移動云 容器服務 Serverless版 https:/ 容器服務 Serverless版，無服務器Kubernetes容器服務。無需購買節點，無需對集群進行節點維護和容量規劃，即可直接部署容器應用，并且只需要為應用配置的CPU和內存資源量進行按需付費。集群中沒有節點費用，Pod基于容器實例按量計費。Thanks.