杭州雲棲，螞蟻和阿里雲的程序員說了場「相聲」

螞蟻金服過去十五年，重塑支付改變生活，爲全球超過十二億人提供服務，這些背後離不開技術的支撐。在2019杭州雲棲大會上，螞蟻金服將十五年來的技術沉澱，以及面向將來的金融技術創新和參會者分享。咱們將其中的優秀演講整理成文並將陸續發佈在「螞蟻金服科技」公號上，本文爲其中一篇。

本文根據雲棲大會容器專場演講內容整理。

你們中午好，感謝你們在飢腸轆轆的中午不離不棄地來到咱們的會場，咱們帶給你們的這段相聲是關於安全容器技術的。我是王旭，半年前剛剛結束一段創業，和團隊一塊兒加入了螞蟻金服，創業期間，2017 年，咱們在德州奧斯汀，和 Intel OTC 一塊兒發佈了 Kata Containers 安全容器項目，是這個項目的創始人之一；和我一塊兒的是阿里雲智能的獎哥，他是阿里雲容器服務 ECI 的臺柱子，也是 rust-vmm 開源項目的積極維護者。

圖左爲螞蟻金服資深技術專家 王旭，圖右爲阿里雲操做系統資深技術專家 劉獎

咱們見證了容器安全和安全容器技術在爭議中的發展，今天想要結合社區裏和阿里雲上安全容器的沿革，談談對安全容器技術將來發展的思考。 此次的分享分爲四個部分：

· 當前容器技術應用和安全問題的現狀

· 安全容器技術發展歷程

· 阿里雲服務中的安全容器

· 咱們乃至整個社區正在作的技術努力

當前容器技術應用和安全問題的現狀

衆所周知，容器化、微服務化、雲原生化是當前 IT 系統演進的趨勢。根據 Portworks 和 Aqua Security 的調查報告顯示，被調查的大多數企業都不是正在使用容器，就是考慮使用容器。 上午過來時和剛纔演講的 Chris 聊天的時候，他也提到，今年年末 San Diego 的 KubeCon 預計會有一萬兩千人來參會，他還特別提到一點：雲原生化不只是改變已有應用的架構，更是促進了更豐富的服務的開發，IT 系統的服務規模是在加速提高的。 不過，儘管容器技術煊赫一時，但挑戰仍是存在的。

能夠看到，大概有半數的企業，尤爲是運行了 100 個以上容器的企業，認爲他們的容器是有安全漏洞的，固然，還有很大比例的人表示並不確認他們的容器是否有安全漏洞。咱們都知道，安全不只是個技術問題，也是個信心問題，粉紅色字的這段就是這個意思，由於對容器安全的擔憂，42% 的受訪者是沒法全身心地擁抱容器生態的。

固然，我得說，關心安全問題是個好的信號，由於只有當你準備把一項技術真正用於生產環境的時候，纔會從安全角度去認真審視它。和其餘領域差很少，容器安全也是一項端到端的技術，從容器鏡像自己的安全性和完整性，到運行容器的軟硬件平臺的基礎設施安全性，再到容器運行時引擎的安全性都須要被照顧到，哪一個均可能成爲最短的那根板子。

安全容器技術發展歷程

說到容器的安全，咱們能夠回到容器的春秋戰國時期了，不談遙遠的 FreeBSD Jail 和 Solaris Zone，咱們從最終進入 Linux Kernel 的這組 Namespaces 和 cGroups 來看，這套容器技術實際上一樣是從進程調度的角度入手，對內核進行的功能擴展，優點上來講，操做界面很 Linux、很方便，開銷也很低，能夠被用來無負擔地套在已有應用外面來構建隔離的環境，而且它是純軟件方案，不和其餘層面的物理機、虛擬機相沖突。

然而，它的問題也在於它仍然是 Linux Kernel 的一個部分，已有的 Linux 的隔離問題沒法根除，甚至可能由於新加入功能而被放大。因此，2015 年西雅圖的 LinuxCon 上，Linus 在 Keynote 上接受訪問的時候，就直接說出，Bug 是沒有辦法的，要安全必需要有隔離層。（原文爲: The only real solution to security is to admit that bugs happen, and then mitigate them by having multiple layers）

隔離層，這裏所謂隔離層就是讓應用容器運行在本身的內核之上，不和其餘容器共享。這裏面最簡單的方案就是把容器放在虛擬機裏跑（左1），這種方式不須要對軟件棧作改動，只是讓同一個用戶的容器跑在本身的虛擬機裏，但這樣帶來的問題，除了額外的開銷以外，還有兩層的維護複雜度。

另外一種源遠流長的獨立內核的方案是 unikernel（右1），讓應用本身帶上本身的內核，這種方式的好處是最簡化的 LibOS 不只能夠有更小的開銷，也能夠有更小的攻擊面，但阻止它被更普遍應用的問題在於它每每須要修改應用，兼容性永遠是平臺技術被採納的最大障礙。

因此，針對未修改的應用的安全容器方案就落在了中間兩種方案——MicroVM 和進程虛擬化上，前者是使用了輕量級虛機和裁剪過的 Linux 內核，在保證兼容性的前提下儘可能下降運行時和維護的開銷，然後者則是使用一個特定的內核來提供 Linux ABI，直接虛擬化進程的運行環境，爲 Linux 應用盡可能提供最大兼容性。

Kata Containers 就是這樣一個 MicroVM 的安全容器方案，首先，對應用來講，這是一個兼容 runC 的容器運行時引擎，能夠被 Kubernetes 經過 containerd/CRI-O 調用，能夠直接運行任何 Docker Image 或 OCI Image。但與 runC 不一樣它使用了硬件虛擬化能力，直接面對用戶應用的再也不是宿主機的內核，而是一個獨立的裝在虛擬機裏的內核，即便有未知的安全漏洞致使這個內核被攻擊，攻擊者仍然沒法輕易突破虛擬化技術構建的沙箱。

Kata Containers 項目由咱們和 Intel 一塊兒在 2017 年開源，去年 4 月份成爲 OpenStack 基金會旗下的七年來第一個頂級開放基礎設施項目。做爲一個社區化項目，這個項目還有不少阿里雲和螞蟻之外的開發者，目前項目正在討論 2.0 版本的路線圖，也歡迎你們爲項目貢獻代碼和需求。

從技術上說，在 Kubernetes 生態裏，Kata Containers 能夠和 runC 同樣對接 containerd 和 CRI-O 這樣的 CRI Daemon，目前咱們推薦的接口是去年暑假在 containerd 社區首先引入的 Shim V2 API，這個 API 目前也被 CRI-O 所支持，Kata 是第一個正式支持這個新接口的容器引擎，經過這個接口，每一個 Pod 的額外 Kata 輔助進程只有一個，不論 Pod 裏面有多少容器，這對宿主機調度器也是比較友好的。

Shim 會經過 vsock 控制 MicroVM 裏面的 agent 來管理 Pod 裏面的 OCI 容器，這裏，社區版本的 Kata 支持的 VMM 包括了 Qemu 和 AWS 開源的 FireCracker，前者功能更豐富、兼容性更好，後者更輕小，根據咱們阿里巴巴的「既要、又要、還要」的精神，你不須要捨棄哪個，用上 Kubernetes 的 RuntimeClass，你能夠爲每一個 Pod 指定要用的 VMM。具體的 How to 類的細節，你能夠看咱們 GitHub 上的文檔也能夠在 Slack channel 裏討論，遇到問題別忘了開 issue，這也是對社區的巨大支持，不是隻有寫代碼纔算貢獻開源的。

相似的基於 MicroVM 類技術的容器方案實際還有很多，耳熟能詳的還有微軟的 Hyper-V Container 和最近在 Windows 裏集成的 WSL2，從數量上說，這類方案是目前的主流，最重要的緣由就是對通常 Docker Image 的完美兼容性，而這種方案裏最正統的開源方案固然就是咱們 Kata 了。固然基於進程虛擬化的方案有不少亮點的，其中最大的亮點固然是 Google 開源的 gVisor 了，由於它開源的時候的 Google 的項目技術 Leader 就是如今個人老闆，何徵宇。

阿里雲安全沙箱的歷史、現狀以及將來

從 2013 年到 2019 年的 6 年時間裏，容器技術及生態每一年都往前邁進一大步，經歷了從提出技術理念、構建合做生態到商業落地應用的飛速發展週期，到達了論壇開篇演講中所提到的「拐點已至」的階段。

讓咱們一塊兒簡要回顧一下阿里雲安全容器與安全沙箱技術的發展歷史。

· Docker 理念被提出一年多以後，2015 年產業界開始共同推動容器技術及生態。阿里雲、Hyper.sh 和 Intel 等都意識到 runC 的侷限性，開始基於虛擬機技術構建容器的安全運行環境。

· 通過一年的研發期，2016 年安全容器技術開始進入生產環境。阿里雲研發的 vLinux 技術在 MaxCompute 場景落地應用，Hyper.sh 也基於 runV 對外提供容器服務。這一年還發生一個很是重要的事情：K8s 定義了 CRI 接口規範，用於對接多種形態的容器運行環境，從而爲安全容器和 K8s 生態的融合提供堅實的基礎。

· 2017 年微軟開放了 ACI 容器服務，阿里雲也研發了基於虛擬機的容器服務。

· 2017 年 12 月，Hyper.sh runV 項目和 Intel Clear Container 項目宣佈合併成立 Kata Container 項目，共同推動基於硬件虛擬化的安全容器運行環境，實現「虛擬機的安全，容器的速度」。

· 2018 年阿里雲開放基於虛擬機的容器服務，同時開始研發基於 MicroVM 路線的安全沙箱技術。這一年 Google 開源了 gVisor，AWS 開源了 firecracker。

· 2019 年，阿里雲安全沙箱技術商用上線，支持 ECI、ACK、SAE 邊緣計算等多種業務。Intel 創立了 Cloud Hypervisor 項目，致力於爲雲原生場景打造專用的 hypervisor。

從 2017 年末開始，Kata、gVisor、Firecracker、Nabla、Cloud Hypervisor 等開源安全容器技術不斷涌現，技術進入井噴期。很是高興的是 Hyper 團隊今年加盟阿里數字經濟體，一塊兒爲咱們的客戶打造安全可靠的容器運行環境。

剛纔介紹中提到了不一樣的容器 runtime 技術，可能你們心中會有個疑問，這些技術的關係和區別是什麼呢？

我以生活中的常見租房爲例來打個比方，方便你們理解容器 runtime 的區別。

· 首先聊聊 Fircracker，Firecracker 並非一個 container runtime，而是一個輕量化的 VMM

· runC 就相似羣租房，裝修簡單、利用率高，可是隔音、安全和入住體驗稍差

· 使用 containerd/CRI-O 接入 Kubernetes 的 Kata 1.x/gVisor 就相似合租房，每一個租戶都有本身獨立的臥室，可是客廳、廚房、衛生間仍是共享的

· 阿里雲安全沙箱相似酒店式公寓，提供全功能的、標準化、帶客房服務的入住體驗

· VM + containerd 則相似租普通住房，公攤面積大，還可能須要本身裝修

阿里雲安全沙箱就是致力於打造酒店式公寓，爲客戶提供拎包入住式的容器服務。

咱們乃至整個社區正在作的技術努力

正如你們所瞭解的，阿里巴巴既有像淘寶、天貓、高德等衆多面向我的消費領域的業務，也有阿里雲、釘釘等面向企業服務的業務。做爲底層基礎技術的安全沙箱技術，須要支持多種應用場景。綜合各類業務場景，大體能概括出三種典型的應用模式：

1. 第一種是面向公共雲服務的容器服務。這種應用場景下，咱們既須要保證基礎設施的安全性，也須要嚴格保證客戶的數據安全以及租戶之間的隔離性。咱們須要提供酒店式公寓而不是羣租房或合租房。

2. 第二種是須要在一臺服務器上同時執行可信代碼和不可信代碼的場景。好比，須要執行用戶上傳的代碼、無源代碼的可執行文件或未經審計的開源代碼的狀況。這是安全沙箱的最典型用法，經過安全沙箱構建一個帶安全邊界的執行環境，把不可信代碼限定在這個受限的執行環境中，從而保護系統中的其它組件。

3. 第三種是多種業務混合部署的場景。爲了提升資源利用率，主流技術思路之一是把在線業務和離線業務混合部署在相同的服務器上，利用在線服務的剩餘資源來爲離線任務服務。這是至關挑戰的一個任務，傳統作法是經過爲在線任務預留足夠的資源來保證在線服務的服務體驗。那麼，混部的狀況下如何保證在線任務的服務體驗呢？思路也很簡單，給予在線業務較高的優先級。可是這還不足夠，因爲共享內核，內存分配、IO 調度方面，離線任務仍是會常常干擾在線任務。因此把離線任務放入獨立的安全沙箱，實現資源隔離、故障隔離、環境隔離。

基於以上的業務需求，咱們研發了阿里雲安全沙箱技術，立足於阿里雲成熟穩定的基礎設施、基於 MicroVM 技術路線，爲業務構建安全、可靠、輕量、生態兼容的容器 runtime。

阿里雲安全沙箱是基於 MicroVM 構建的安全容器 runtime。首先它是一個基於硬件虛擬化技術的 MicroVM，採用了深度定製優化 hypervisor，極簡的虛擬機設備模型，VMM 基本上不訪問 guest memory。其次阿里雲安全沙箱也是一個容器 runtime，提供鏡像分發、鏡像管理、容器網絡、容器存儲，徹底兼容 OCI 和 CRI 規範。

阿里雲安全沙箱的安全來源於新型安全系統語言、極小而可控的源代碼、極簡的設備模型、深度定製的 Hypervisor以及安全加固的阿里雲 Linux for Sandbox 系統。

那麼，阿里雲安全沙箱能給客戶帶來什麼價值呢？除了安全可靠外，阿里雲安全沙箱還會給客戶帶來極速啓動、極致彈性和低資源開銷。實際測試數據代表，去掉下載容器鏡像的時間，阿里雲安全沙箱啓動容器實例耗時小於500毫秒，在 96CPU 的系統上每秒啓動實例數量大於 200 個，平均每一個 microvm 的內存資源好用小於 2.5M。 那麼安全容器的下一步挑戰是什麼呢？用戶理想中的容器運行 runtime 是什麼樣的呢？

· 超越虛擬機的安全性

· 像本機運行同樣的性能

· 像 runC 同樣的兼容性和易用性

在過去，螞蟻金服和阿里雲就是安全容器的積極貢獻者，在接下來的時間裏，咱們仍然會繼續和開源社區緊密合做。

咱們會開放地和社區共同制定 Kata Containers 2.0 的路線圖，把咱們在容器和雲服務領域的最佳實踐反饋給社區，將通用性的技術貢獻到 Kata Contaienrs 和 Rust-VMM 社區，保證阿里巴巴 CloudSandbox 和社區的一致性，和業界一塊兒爲廣大用戶打造一個安全、可靠、高效和兼容生態的容器 runtime。