目前，容器和鏡像已經成爲應用打包和交付的事實標準，同時，Kubernetes 也成爲應用容器的標準 OS。作爲雲原生應用中最關鍵的技術之一，容器已經被大部分用戶應用到生產環境中。但是，有研究報告顯示，容器安全已經成爲用戶容器化應用的最大阻力。
容器安全的現狀是什麼？業界主要有哪些容器運行時安全技術或解決方案？企業對安全容器的訴求有哪些？… 針對容器安全的有關問題，InfoQ 記者採訪了阿里巴巴技術專家高步雙（花名：江博）。
容器安全的現狀
高步雙認爲，與傳統安全相比，雲原生時代的安全挑戰發生了很大變化，主要表現在三方面：
- 如今，一臺服務器可能混合運行着成百上千個應用容器，其密度是傳統模式的數十倍
- 容器和鏡像加速了敏捷快速迭代的效率，應用變更更加頻繁
- 在開放的雲原生時代，有越來越多的開源技術和三方不可信應用被引入到企業內部
隨着越來越多的應用容器化後，暴露的安全問題也更加嚴峻。以漏洞爲例，自 2017 年以來，業界已經曝出 25+ 與 Kubernetes 相關的 CVE 漏洞。比如 CVE-2019-5736 runC 漏洞，它能讓普通用戶身份運行的惡意程序滲透到宿主機，修改 runC 程序，在下次創建容器時就會調用被修改的 runC，藉此，攻擊者可以實現任何非法目的。
“以往，一臺機器只部署一個應用，容器化後，一臺機器可能混合部署着各種各樣的應用，這無疑提高了應用自身的安全風險。”他說。
此外，有越來越多的用戶開始關注容器安全。根據 Tripwire 發佈的“2019 年容器安全現狀”報告表明，有高達 94% 的受訪對象對容器安全比較關注，只有 6% 的受訪者表示並不在乎。
在高步雙看來，容器安全問題的影響可大可小。“逃逸的惡意容器應用會滲透到內網網絡，嗅探網絡、竊聽，盜取重要數據，甚至對內網中的服務或其他業務應用發起攻擊，給整個公司帶來嚴重的負面影響，帶來的損失有時甚至無法估量”。
容器安全分類
容器安全涉及範圍較廣，一般分成三大類：
運行時安全
- 安全容器運行時（簡稱安全容器，隔離不可信應用、阻斷惡意非法訪問）
- 網絡隔離（Network Policy 等）
- 漏洞檢測（主機 OS、Guest 等）
- 安全監控（進程異常行爲、網絡活動等檢測）
軟件供應鏈
- 數據保護（At-Rest、In-Use、In-Transit）
- 鏡像安全（鏡像簽名、鏡像掃描）
- DevSecOps
基礎設施安全
- RAM 認證
- 細粒度 RAM 授權
這些容器安全問題中，最有挑戰性的是容器安全運行時問題。從縱向看，安全容器技術涉及到硬件、OS、Kernel、Hypervisor、容器、K8s 等多層複雜技術；從橫向看，涉及到網絡、存儲、監控、日誌等適配。
以傳統的 runC 容器爲例，其最大的問題是隔離問題，包括系統隔離、數據隔離、網絡隔離等安全隔離問題，還有性能和故障隔離，比如隔離不足、資源爭搶導致延遲敏感型應用抖動、主機上的容器故障（CPU 泄露、頻繁 CoreDump 等）都會影響主機上的其他容器。
此外，由於 runC 容器基於 Namespace 技術隔離，導致大部分非 Namespace 類別的內核參數的設置會影響主機上的所有其他容器。
業界主要的安全容器運行時技術對比
根據高步雙介紹，業界安全容器運行時主要分爲四大類：
OS 容器 + 安全機制
它的主要原理是在傳統 OS 容器之上增加一些安全輔助手段來提高安全性，如 SELinux、AppArmor、Seccomp 等，還有 docker 19.03+ 可以讓 Docker 運行在 Rootless 的模式之下。其實，這些都是通過輔助的工具手段來增強 OS 容器的安全性，但依然沒有解決容器與 Host 共享內核利用內核漏洞逃逸帶來的安全隱患問題；而且，這些安全訪問控制工具對管理員的認知和技能要求比較高，安全性也相對最差。
用戶態內核
此類典型代表是 Google 的 gVisor，通過實現獨立的用戶態內核去捕獲和代理應用的所有系統調用，隔離非安全的系統調用，間接性達到安全目的，它是一種進程虛擬化增強。
但是，系統調用的代理和過濾的這種機制，導致它的應用兼容性以及系統調用方面性能相對傳統 OS 容器較差。由於並不支持 virt-io 等虛擬框架，擴展性較差，不支持設備熱插拔。
Library OS
基於 LibOS 技術的這種安全容器運行時，比較有代表性是 UniKernel、Nabla-Containers。LibOS 技術本質上是針對應用內核的一個深度裁剪和定製，需要把 LibOS 與應用編譯打包在一起。因爲需要打包拼在一起，因此本身兼容性比較差，應用和 LibOS 的捆綁編譯和部署，這爲傳統的 DevOps 帶來挑戰。
MicroVM
目前，業界虛擬化 (機) 本身已經非常成熟，MicroVM 輕量虛擬化技術是對傳統虛擬化的裁剪，比較有代表性的就是 Kata-Containers、Firecracker，擴展能力非常優秀。VM GuestOS 包括內核均可自由定製，由於具備完整的 OS 和內核，它的應用兼容性極其優秀；獨立內核的好處是即便出現安全漏洞問題也會把安全影響範圍限制到一個 VM 裏面。當然，它也有自己的缺點，Overhead 可能會略大一點，啓動速度相對較慢一點。
如何選擇安全容器運行時？
對企業而言，它在選擇安全容器運行時需要考慮三個方面：安全隔離、通用性以及資源效率。如下圖所示：
具體而言，安全隔離注重不可信應用的安全隔離、故障隔離以及性能隔離；標準通用注重應用兼容性、K8sAPI、OCI 標準兼容以及原生性；資源效率注重應用性能、啓動速度以及更低的 overhead 開銷。
高步雙向 InfoQ 記者指出：如何去平衡這三個方面，主要還是根據用戶自己的業務場景和技術能力去選擇，安全容器往往涉及從硬件、OS、Kernel、容器引擎、容器 Runtime、K8s 等多個層面的技術問題，同時還需要打通周邊網絡、存儲、日誌、監控等系統，門檻較高。
- 對大部分內部可信業務來說，這類應用安全風險較低，普通的 runC 容器足矣；
- 對來自三方、開源或存在潛在漏洞風險的應用，需要通過安全容器進行隔離；若追求高執行效率和更小的開銷，可以考慮 LibOS 形態的安全容器，缺點是需要 LibOS 和應用捆綁編譯；若追求通用性，可以考慮基於輕量虛擬機技術的安全容器，比如開源的 Kata Containers、firecracker，也可以考慮公有云安全容器產品，例如 ACK 安全沙箱容器等，雖然基於虛擬機技術，但依然能做到秒級創建和啓動。
另外，開源的用戶態內核實現，比如 gVisor，雖然開銷較小、啓動速度較快，但是兼容性稍差於 runC 以及輕量虛擬機安全容器。
安全容器在阿里 WebIDE 上的實踐
高步雙稱，“除了邊緣計算場景，安全沙箱容器也是很多雲產品的底座，比如阿里的宜搭、WebIDE，外部的客戶，比如銀行、金融科技類公司等。”
這裏以安全容器在 WebIDE 上的應用爲例。WebIDE 是阿里云云端集成開發平臺，用戶僅需要打開瀏覽器，就能隨時隨地的編寫代碼、調試程序並提交部署，它還支持萬人在線。並且，WebIDE 集成了 Theia 和開天（阿里自研）的前端，兼容 VSCode 插件。
據悉，整個 WebIDE 系統都是通過雲原生技術、基於 ACK 神龍裸金屬沙箱容器 K8s 集羣打造的。同時，它也被 WrokBench、宜搭等雲上產品和阿里集團內大量業務系統所集成。在支撐 WebIDE 的業務場景中，用戶的每個開發空間都有獨立的 Deployment、Service、Ingress、PV/PVC 等配置，並且萬人在線的規模也帶來了諸多挑戰。
挑戰 1：海量 Ingress 路由規則，社區 Nginx Ingress 長連接 reload 斷連、LUA 反向代理轉發間斷性卡頓（70ms ->1.5s）。
這其中有兩個問題：第一個問題，在 WebIDE 中，瀏覽器通過 WebSocket 與服務端交互，集羣內大量的 service、ingress 對象，一旦任何對象發生變更，都會導致整個 Nginx Ingress Controller 重新 reload，引發長連接斷連。
對這個問題，他們的解決辦法是在社區 Nginx Ingress Controller 的基礎上增加“dynamic-servers（動態 servers）功能。這裏，解決的很重要的一點是配置（Http、Server、Upstream、Location 等）變更時，Nginx 不去 reload，這樣就不會 fork 新的 worker 進程。將這些頻繁變化的配置放到 Shared Memory（LUA）中，當 Nginx 接收請求時，就能基於最新的共享內存中的配置規則進行規則匹配和路由轉發。
第二個問題，經排查和測試發現，當集羣 Ingress 對象數量超過 600 個左右後，LUA 轉發出現了明顯的間斷性卡住，響應時間從 70ms 左右劇增到 1.5s 左右。
如何解決這個問題？他們首先想到的方案是替換 Ingress Controller 方案，不僅測試了 Nginx 官方版本的 Nginx Ingress Controller，而且還測試了 gloo、contour 等基於 Envoy 實現的 Ingress Controller。
測試後發現，Nginx 官方版本的 Nginx Ingress Controller 並未提供動態 servers 等功能，reload 後在 worker_shutdown_timeout 會強制導致長連接斷連。
gloo、contour 等基於 Envoy 實現的 Ingress Controller，在處理海量的 Ingress 對象（2k+) 性能上並未出現卡頓問題，單純從反向代理轉發性能來看，仍然可以看出 Envoy 的轉發性能略差於 Nginx。
分片方案
考慮到集羣業務規模的急速增長，每個 Ingress Controller 實例仍要處理所有集羣 Ingress 對象路由，在規模大到一定量時，必然面臨性能問題，所以團隊想到了“分片”方案。詳解方案前，我們先看看原生 Nginx Ingress 架構圖：
分片方案 1：
通過 ingress-class 爲 ingress 對象分片，每一個 class 都是一個獨立的 ingress 集羣，它的缺點是對用戶有感，運維複雜，橫向擴容 class 需要增加 ingress LoadBalancer 等，所以後來放棄這個方案。
分片方案 2：
團隊決定基於一致性 Hash 開發了一個 Ingress Chunk Controller 的分片版本，方案如下：
方案核心原理解釋：
- Ingress Controller 劃分成不同的分片，如上圖 chunk-1、chunk-2…chunk-10 等，每個 chunk 內的 Ingress Controller（稱爲 Member）只負責一致性 Hash 算法過濾出的 Ingress 對象路由；
- 在“Ingress 路由層”之上新增“Chunk 路由層”，Chunk 路由層負責將 http 請求根據相同的 Hash 算法路由到繆戈 Chunk 上。
這打散了 Ingress 對象的分佈，讓每個 Nginx-Ingress-Controller（member）只負責少量的 Ingress 對象，而非純粹去優化單體 Controller 的性能（如優化 LUA 腳本、Envoy 替代等），這樣做的最大好處是 Ingress-Chunk 理論上可以無限橫向擴容，而且 Nginx-Ingress-Controller 可與社區保持更新。
IngressChunkController上線後，斷連問題得到有效的解決，雖然增加了一層 Chunk 路由層，但是響應時間僅僅增加了幾十微秒。“我們不久也會把 IngressChunkController 在阿里雲 ACK 的應用目錄開放給所有用戶”。
挑戰 2：海量 K8s 對象給 Master、Addons 組件帶來了巨大壓力
據悉，海量 K8s 對象給 Master 和 Addons 組件帶來了巨大壓力，PV/PVC 創建變慢、Ingress 路由規則生效慢、網絡策略插件 CPU 佔用 800% 等一系列的問題。
對於上述問題，首先得益於 ACK 託管架構，可以輕鬆地爲用戶縱向擴容 Master 組件規格；其次，優化 Kube-controller-manager 的 List/Watch API 限速配置，解決了 PV/PVC、Ingress 路由規則生效慢等問題；然後，通過 calico-typha 中心化方案，將計算邏輯從 calico-felix 剝離到 typha 中，讓節點 calico-felix CPU 佔用從 800% 下降到 10%。
挑戰 3：多租戶網絡、用戶 VPC 打通，讓用戶在自己的業務空間使用自己 VPC 內的資源
上圖是典型 Serverless 場景中解決多租戶網絡問題，資源（Pod、神龍）實際屬主爲產品方，運維、神龍等成本由產品方承擔，大大降低用戶的運維成本和資源成本。
用戶期望在 Pod 內可以訪問自己 VPC 內的資源，比如 RDS、應用服務等。但是 Pod 實際 VPC 和用戶 VPC 是兩個完全獨立隔離的 VPC，那兩者之間的網絡應該如何打通？
產品方可以通過授權和角色扮演的方式，在用戶 VPC 內購買一個 ENI 網卡，並將這個網卡綁定到產品 VPC 神龍的 Pod 內。
挑戰 4：極速文件共享，對存儲性能提出挑戰
存儲插件（如 CSI-Plugin）會把存儲（如 NAS、雲盤、OSS 等）先掛載到宿主機的一個目錄，然後通過 mount bind 方式共享到容器內，這在 runC 容器上沒有問題，但是在安全沙箱容器上會經過 9PFS，導致性能急劇下降數十倍甚至數百倍，所以採用了“存儲直掛（直通）”方案。
阿里巴巴的最新探索
在數字經濟時代，數據保護問題已經成爲企業上雲最大的挑戰之一。
高步雙認爲，數據有三種形態：At-Rest（存儲狀態）、In-Tranist（傳輸狀態）和 In-Use（使用中或計算中狀態）。其中，前兩種狀態下的數據加密和數據保護的技術與產品已經相當成熟，加密數據在內存中，計算前通常會先解密，理論上，可以從內存獲取解密後的明文數據或密鑰。而如果想幫助用戶保護 In-Use 狀態下的數據，那麼隱祕性和安全性則成爲最大的難題。安全容器（如 ACK 安全沙箱等）可以幫助我們很好地隔離不可信應用，避免逃逸、滲透到後端造成無法估量的破壞，但是無法幫用戶保護自己計算過程中（In-Use）的敏感數據或代碼不被其他應用、管理員、運維人員、黑客甚至雲廠商竊取。爲此，他們和螞蟻、操作系統、雲安全以及神龍等多個團隊合作，在阿里雲容器服務 ACK-TEE 上推出了基於 Intel SGX 的“加密計算”集羣。
Intel SGX 是 Intel 爲軟件開發者提供的安全技術，是把用戶應用程序代碼和數據運行在一個通過硬件孤島和內存加密技術創建的特殊執行上下文環境 Enclave 中（此環境也可統稱爲可信執行環境 TEE – Trusted Execution Environment），任何其他應用、OS、Kernel、BIOS，甚至 CPU 之外的其他硬件均無法訪問，並且 Enclave 內存中的數據全部是加密的。用戶用自己的從 Intel 申請到的祕鑰簽名 & 加密 Enclave 裏的代碼和數據，Enclave 必須通過遠程證明服務（Intel IAS）驗證簽名通過纔可以正常啓動。
此外，爲降低可信應用的開發和交付門檻，高步雙所在的團隊還聯合操作系統安全團隊主導開源了業界第一款面向機密計算容器運行時項目 Inclavare Containers，它可以讓用戶很輕鬆地創建一個基於硬件孤島和加密的可信執行環境，幫助用戶在雲上保護自己的敏感數據和應用；同時，它兼容 OCI 標準，傳統應用容器無需或少量修改即可運行在可信執行環境（TEE）中，用戶無需通過 SDK 重構應用，極大提高了可信應用的交付效率。
企業對安全容器的 3 大訴求
當前，雲原生基礎設施主流架構主要是 CaaS+Serverless，未來將向 Serverless+fPaaS（FaaS）演進，應用也會越來越輕量化，而輕量應用也會要求更高的靈活性，極致的彈性效率和更小的計算單位以及更低的成本。這些訴求必然對基礎設施帶來新的挑戰。
在高步雙看來，未來的安全容器運行時將發生以下變化：
- 邊界突破
數字經濟時代，越來越多的應用和數據需要安全容器保護，安全容器的用途將不再是單一的隔離不可信應用。
- 更輕更快
在保障安全性的前提下，未來的應用對安全容器的啓動速度和 overhead 都提出了更高要求，啓動速度從秒級降爲毫秒級，內存開銷從數百兆降低到數十兆，這將極大提高新時代應用交付效率，降低計算成本。
- 富運行時
在未來，單一的安全容器運行時無法滿足需求。即使安全容器運行時不斷在瘦身和優化，但對於輕應用而言，仍顯得過重，這將催生應用運行時（Application Runtime）的產生，比如 WebAssembly 等。但是，應用運行時在資源隔離限制等方面存在一定的不足，通過 SecureContainerRuntime + ApplicationRuntime，既可以滿足安全、資源隔離，又能滿足輕應用的靈活調度和部署。
在可信應用和隱私數據保護方面，通過 SecureContainerRuntime +TEE Runtime，不僅可以保護應用，而且能避免應用受到外部的非法訪問，實現雙向隔離。
寫在最後
雖然大部分終端用戶還在使用 Docker runC 容器，但在各類 Serverless、FaaS 雲產品雲集的今天，安全容器已經成爲這些雲產品必備的安全隔離底座，有越來越多的用戶開始選擇安全容器替代 runC 運行時。“隨着安全容器啓動效率、overhead 的極致優化，甚至在某些場景優於 runC 容器，在兼容性、性能、啓動效率、幾乎可忽略的 overhead，安全容器會越來越普及”。