沙盒化容器：是容器還是虛擬機
隨着 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[1] 是使用 Go 編寫的應用內核，實現了 Linux 操作系統的大部分接口。其包含了一個叫做 runsc 的 OCI 運行時，提供了應用和宿主機內核間的隔離層。runsc 也實現了與 Docker 和 Kubernetes 的集成，可以很容易的運行沙盒容器。
gVisor 爲每個容器提供了獨立的操作系統內核。應用與 gVisor 內核提供的虛擬環境進行交互，不是直接訪問宿主機的內核。gVisor 還限制和管理文件和網絡操作，確保容器化應用和主機操作系統之間有兩個隔離層。通過減少和限制應用與主機內核的交互，儘可能減小攻擊者繞過容器隔離機制的攻擊面。
與大部分內核不同，gVisor 不需要固定的物理資源；相反，其利用現有的主機內核功能，並作爲一個正常進程運行。換句話說，gVisor 以 Linux 的方式實現了 Linux。
gVisor 沙盒由多個進程組成，這些進程共同構成了可以運行一個或多個容器的環境。
每個沙盒都有其獨立的實例：
•Sentry：運行容器的內核，攔截並響應應用的系統調用。
沙盒中的每個容器都有其獨立的實例：
•Gofer：提供容器文件系統的訪問。
Kata Containers
Kata Containers[2] 與容器一樣輕量級且快，並與容器管理層集成 -- 包括 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 很好的集成。
引用鏈接
[1] gVisor: https://github.com/google/gvisor
[2] Kata Containers: https://katacontainers.io
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/qFQBBpjUoqdfnmCeOGqRJQ