隨著 IT 技術的發展，AI、區塊鏈和大資料等技術提升了對應用毫秒級擴充套件的需求，開發人員也面臨著的功能快速推出的壓力。混合雲是新常態，數字化轉型是保持競爭力的必要條件，虛擬化成為這些挑戰的基本技術。
在虛擬化的世界，有兩個詞耳熟能詳：虛擬機器和容器。前者是對硬體的虛擬化，後者則更像是作業系統的虛擬化。兩者都提供了沙箱的能力：虛擬機器通過硬體級抽象提供，而容器則使用公共核心提供程式級的隔離。有很多人將容器看成是“輕量化的虛擬機器”，通常情況下我們認為容器是安全的，那到底是不是跟我們想象的一樣？
容器：輕量化的虛擬機器？
容器是打包、共享和部署應用的現代化方式，幫助企業實現快速、標準、靈活地完成服務互動。容器化是建立在 Linux 的名稱空間（namespace）和控制組（cgroup） 的設計之上。
名稱空間建立一個幾乎隔離的使用者空間，併為應用提供專用的系統資源，如檔案系統、網路堆疊、程式ID和使用者ID。隨著使用者名稱空間的引入，核心版本 3.8 提供了對容器功能的支援：Mount（mnt）、程式 ID（pid）、Network（net）、程式間通訊（ipc）、UTS、使用者 ID（user）6 個名稱空間（如今已達 8 個，後續加入了 cgroup 和 time 名稱空間）。
cgroup 則實施對應用的資源限制、優先順序、記賬和控制。cgroup可以控制 CPU、記憶體、裝置和網路等資源。
同時使用 namespace 和 cgroup 使得我們可以在一臺主機上安全地執行多個應用，並且每個應用都位於隔離的環境中。
虛擬機器提供更強大的隔離
雖然容器很棒，足夠輕量級。但通過上面的描述，同一個主機上的多個容器其實是共享同一個作業系統核心，只是做到了作業系統級的虛擬化。雖然名稱空間提供了高度的隔離，但仍然有容器可以訪問的資源，這些資源並沒有提供名稱空間。這些資源是主機上所有容器共有的，比如核心 Keyring、/proc、系統時間、核心模組、硬體。
我們都知道沒有 100% 安全的軟體，容器化的應用也一樣，從應用原始碼到依賴庫到容器 base 映象，甚至容器引擎本身都可能存在安全漏洞。發生容器逃逸的風險遠高於虛擬機器，黑客可以利用這些逃逸漏洞，操作容器的外部資源也就是宿主機上的資源。除了漏洞，有時使用的不當也會帶來安全風險，比如為容器分配了過高的許可權（CAP_SYS_ADMIN 功能、特權許可權），都可能導致容器逃逸。
而虛擬機器依靠硬體級的虛擬化，實現的硬體隔離比名稱空間隔離提供了更強大的安全邊界。與容器相比，虛擬機器提供了更高程度的隔離，只因其有自己的核心。
由此可見，容器並不是真正的“沙盒”，也並不是輕量化的虛擬機器。有沒有可能為容器增加一個更安全的邊界，儘可能的與主機作業系統隔離，做到類似虛擬機器的強隔離，使其成為真正的“沙盒”？
沙盒化容器
答案是有，就是沙盒容器。這種容器就像虛擬機器一樣有自己的核心，這層核心成為使用者空間核心。這層核心要保持容器的輕量級，使用現代程式設計技術編寫，本身非常輕，僅用於作為容器和主機之間的強隔離層。
並且還要支援 OCI 和 CRI 規範，可以與 Docker 和 Kubernetes 等容器工具很好的整合。
這裡簡單介紹下 gVisor 和 Kata Containers。
gVisor
gVisor 是使用 Go 編寫的應用核心，實現了 Linux 作業系統的大部分介面。其包含了一個叫做 runsc 的 OCI 執行時，提供了應用和宿主機核心間的隔離層。runsc 也實現了與 Docker 和 Kubernetes 的整合，可以很容易的執行沙盒容器。
gVisor 為每個容器提供了獨立的作業系統核心。應用與 gVisor 核心提供的虛擬環境進行互動，不是直接訪問宿主機的核心。gVisor 還限制和管理檔案和網路操作，確保容器化應用和主機作業系統之間有兩個隔離層。通過減少和限制應用與主機核心的互動，儘可能減小攻擊者繞過容器隔離機制的攻擊面。
與大部分核心不同，gVisor 不需要固定的物理資源；相反，其利用現有的主機核心功能，並作為一個正常程式執行。換句話說，gVisor 以 Linux 的方式實現了 Linux。
gVisor 沙盒由多個程式組成，這些程式共同構成了可以執行一個或多個容器的環境。
每個沙盒都有其獨立的例項：
Sentry：執行容器的核心，攔截並響應應用的系統呼叫。
沙盒中的每個容器都有其獨立的例項：
Gofer：提供容器檔案系統的訪問。
Kata Containers
Kata Containers 與容器一樣輕量級且快，並與容器管理層整合– 包括 Docker 和 Kubernetes 等流行的容器編排工具 – 同時還提供了與虛擬機器一樣的安全。
Kata Containers 與 OCI、容器執行時介面（CRI）和容器網路介面（CNI）完全整合。它支援各種型別的網路模型（例如，passthrough、MacVTap、橋接、tc 映象）和可配置的訪客核心，以便需要特殊網路模型或核心版本的應用都可以在上面執行。上圖顯示了 Kata VM 中的容器如何與現有編排平臺互動。
Kata 在主機上有一個 kata 執行時來啟動和配置新容器。對於 Kata VM 中的每個容器，主機上都有一個相應的 Kata Shim。Kata Shim 接收來自客戶端（例如 docker 或 kubectl）的 API 請求，並通過 VSock 將請求轉發給 Kata VM 內的代理。Kata 容器進一步進行了幾項優化，以減少 VM 啟動時間。
Kata Containers 由兩個開源專案合併而來：Intel 的 Clear containers 和 Hyper runV。前者注重效能（引導時間小於 100ms）和安全；而後者通過支援不同的 CPU 架構和管理系統，將技術無關放在首位。Kata Containers 可以說集二者之大成。
與傳統的容器相比，Kata Container 做到了虛擬機器的隔離，集虛擬機器的安全性和容器的效能於一身。
總結
與普通容器相比，沙盒容器提供了更強的隔離性，這種強隔離提供了更高的安全性。同時這類容器技術支援 OCI 和 CRI 規範，可以與現有的容器工具以及 Kubernetes 很好的整合。
本作品採用《CC 協議》，轉載必須註明作者和本文連結