安全沙箱核心優勢

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

ACK安全沙箱相比社區Kata Containers，在性能上面具有較大優勢，如下表所示。

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容器。