安全沙箱概述 - Container Service for Kubernetes

安全沙箱運行時將應用及其依賴環境運行在一個輕量級虛擬機器中，為應用Pod提供獨立核心層類比或者細粒度的隔離層，這樣可以有效防止容器內部的惡意攻擊或漏洞，避免影響到宿主機或其他容器。本文為您介紹安全沙箱的架構、核心優勢和常用情境。

背景資訊

安全沙箱特別適合於不可信應用隔離、故障隔離、效能隔離、多使用者間負載隔離等情境。在提升安全性的同時，對效能影響非常小，並且具備與Docker容器一樣的使用者體驗，例如日誌、監控、彈性等。

並且相比社區方案（Kata Containers），安全沙箱在儲存、網路和穩定性方面都有最佳化和提升。

架構圖

核心優勢

安全沙箱v2是阿里雲全新自研的基於輕量虛擬機器技術的安全容器運行時，相比於v1版本，在保持超強隔離性的同時，overhead降低了90%，沙箱啟動速度提升了3倍，單機密度提升了10倍。主要核心優勢如下：

基於輕量虛擬機器，實現沙箱之間的超強隔離。
具有傳統runC容器的應用相容性。
應用綜合效能高，達到runC容器應用效能的90%。
NAS、雲端硬碟、OSS Volume支援virtiofs掛載並共用到沙箱模式。其中，NAS也支援直接掛載沙箱模式。
在監控、日誌、儲存等方面有著runC一致的使用體驗。
支援RuntimeClass（runC和runV），更多資訊，請參見RuntimeClass。
技能門檻要求低、簡單易用。
相比社區Kata Containers，穩定性更強。有關Kata Containers的詳細資料，請參見Kata Containers。

ACK安全沙箱和社區Kata Containers對比

效能	效能分類	ACK安全沙箱v2	社區Kata Containers

效能	效能分類	ACK安全沙箱v2	社區Kata Containers
沙箱啟動速度		約150ms	約500ms
沙箱額外開銷		低	高
容器RootFS		virtio-fs，效能：☆☆☆☆	9pfs，效能：☆ virtio-fs, 效能：☆☆☆☆
容器儲存卷	HostPath/EmptyDir	virtio-fs，效能：☆☆☆☆
	雲端硬碟Block Storage	virtio-fs，效能：☆☆☆☆
	NAS檔案儲存體	virtio-fs（預設），效能：☆☆☆☆ 直掛沙箱，效能：☆☆☆☆☆
	OSSObject Storage Service	virtio-fs，效能：☆☆☆☆
網路外掛程式		Terway：比Flannel網路效能提升了20%~30%，支援NetworkPolicy，頻寬限速等。更多特性請參見Terway網路外掛程式。 Flannel：支援VPC路由。	Flannel
監控警示		增強了安全沙箱Pod的磁碟和網路監控指標。預設整合了阿里雲CloudMonitor，可方便地配置叢集的監控警示。	缺失安全沙箱Pod的磁碟和網路監控指標。
穩定性		☆☆☆☆☆	☆☆

ACK安全沙箱適用情境

情境一：相對於runC容器，安全沙箱（runV）容器可以強隔離不可信應用

runC容器的安全風險
- 通過Namespace和Cgroups技術隔離的容器攻擊面大。
- 節點上所有容器共用Host Kernel，一旦核心出現漏洞，惡意代碼會逃逸到Host上，滲透到後端內網，執行惡意特權代碼，破壞系統服務和其他應用，竊取重要資料等。
- 應用本身的漏洞同樣會造成攻擊者滲透到內網。
您可以通過以下措施降低runC容器的安全風險：
- Seccomp：系統調用過濾。
- SElinux：限制容器進程、檔案和使用者的許可權。
- Capability：限制容器進程Capability。
- Rootless模式：禁止使用者以root身份運行容器Runtime和容器。
雖然以上措施可以在一定程度上強化runC容器的安全性，降低惡意容器應用攻擊Host Kernel的幾率，但是仍然無法解決容器逃逸利用Host Kernel漏洞的安全問題。
安全沙箱（runV）容器隔離潛在安全風險
通過把存在潛在安全風險的應用放置到成熟的輕量級虛擬機器沙箱中，應用運行在獨立的GuestOS Kernel上，即便GuestOS Kernel出現安全性漏洞，那麼攻擊破壞面僅限於一個沙箱內，不會對Host Kernel以及其他容器有任何影響。安全沙箱（runV）容器配合Terway的NetworkPolicy能力，可以靈活地配置Pod的網路存取原則，真正做到系統隔離、資料隔離以及網路隔離。

情境二：解決runC容器在故障放大、資源爭搶、效能幹擾方面的問題。

Kubernetes使得我們很容易在一個節點上混合部署不同的應用程式容器，由於Cgroups並不能很好解決資源爭搶問題，導致同一節點上相同資源密集型（如CPU密集型、IO密集型等）的不同應用相互爭搶資源，導致應用的回應時間出現了嚴重的波動，總體回應時間偏長。當節點上某一應用異常和故障，如記憶體泄露、頻繁CoreDump等等導致節點整體負載升高，單容器觸發Host Kernel Bug導致系統宕機，單應用的故障延展到了整個節點，甚至進一步導致整個叢集的不響應。安全沙箱（runV）容器通過獨立的GuestOS Kernel和Hypervisor，可以很好地解決runC容器在故障放大、資源爭搶、效能幹擾方面的問題。

情境三：多租戶服務

通常一個企業內有多個業務線或部門部署自己的應用，不同的業務線或部門（多個租戶）之間有著較強的隔離訴求，如金融類業務不期望自己的實體環境運行著其他非安全敏感應用，傳統runC容器是無法有效避免不可信應用帶來的潛在安全風險。這種情況下，通常會選擇：

多個單租戶叢集，如金融業務叢集和其他非安全敏感業務分隔到多個獨立叢集。
單個多租戶叢集，需把不同企業營運應用程式分隔到不同的Namespace中，每個節點只可被某個業務線獨佔，配合資源配額、網路原則等實現多租戶隔離。相對於多個單租戶叢集，管控面較少，管理成本較低，但仍然沒有解決因某些租戶資源使用率低導致節點資源閑置浪費問題。

有了安全沙箱（runV）容器後，可以把叢集內不可信應用通過虛擬機器沙箱隔離起來，而不用擔心不可信應用程式容器逃逸造成的安全風險，這樣所有節點都可以混合各類應用程式容器，這樣做的好處是：

減少了資源調度的複雜度。
節點不再被單個業務獨佔，減少資源片段，提高節點資源使用率，節省叢集整體資源成本。
安全沙箱（runV）容器使用輕量級虛擬機器，效能媲美runC容器。