1. 程式人生 > >安全容器的發展與思考

安全容器的發展與思考

作者:
王旭 螞蟻金服資深技術專家,kata containers 架構委員會成員
劉獎 阿里雲作業系統資深技術專家

本文根據雲棲大會容器專場演講內容整理,關注阿里巴巴雲原生公眾號,回覆“安全”獲得本文 PPT

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

(圖左為螞蟻金服資深技術專家 王旭,圖右為阿里雲作業系統資深技術專家 劉獎)

我們見證了容器安全和安全容器技術在爭議中的發展,今天想要結合社群裡和阿里雲上安全容器的沿革,談談對安全容器技術未來發展的思考。 這次的分享分為四個部分:

  • 當前容器技術應用和安全問題的現狀
  • 阿里雲內外的安全容器技術發展的歷程
  • 阿里雲服務中的安全容器
  • 我們乃至整個社群正在做的技術努力

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

眾所周知,容器化、微服務化、雲原生化是當前 IT 系統演進的趨勢。根據 Portworks 和 Aqua Security 的調查報告顯示,被調查的大多數企業都不是正在使用容器,就是考慮使用容器。 上午過來時和剛才演講的 Chris 聊天的時候,他也提到,今年年底 San Diego 的 KubeCon 預計會有一萬兩千人來參會,他還特別提到一點:雲原生化不僅是改變已有應用的架構,更是促進了更豐富的服務的開發,IT 系統的服務規模是在加速提升的。 不過,儘管容器技術炙手可熱,但挑戰還是存在的。這裡需要引用一個 tripwire 調查報告,來源連結在這裡。

可以看到,大概有半數的企業,尤其是運行了 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 則類似租普通住房,公攤面積大,還可能需要自己裝修

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

我們乃至整個社群正在做的技術努力

 正如大家所瞭解的,阿里巴巴既有像淘寶、天貓、高德等眾多面向個人消費領域的業務,也有阿里雲、釘釘等面向企業服務的業務。作為底層基礎技術的安全沙箱技術,需要支援多種應用場景。綜合各種業務場景,大致能歸納出三種典型的應用模式: 

  • 第一種是面向公共雲服務的容器服務。這種應用場景下,我們既需要保證基礎設施的安全性,也需要嚴格保證客戶的資料安全以及租戶之間的隔離性。我們需要提供酒店式公寓而不是群租房或合租房。

  • 第二種是需要在一臺伺服器上同時執行可信程式碼和不可信程式碼的場景。比如,需要執行使用者上傳的程式碼、無原始碼的可執行檔案或未經審計的開原始碼的情況。這是安全沙箱的最典型用法,通過安全沙箱構建一個帶安全邊界的執行環境,把不可信程式碼限定在這個受限的執行環境中,從而保護系統中的其它元件。

  • 第三種是多種業務混合部署的場景。為了提高資源利用率,主流技術思路之一是把線上業務和離線業務混合部署在相同的伺服器上,利用線上服務的剩餘資源來為離線任務服務。這是相當挑戰的一個任務,傳統做法是通過為線上任務預留足夠的資源來保證線上服務的服務體驗。那麼,混部的情況下如何保證線上任務的服務體驗呢?思路也很簡單,給予線上業務較高的優先順序。但是這還不足夠,由於共享核心,記憶體分配、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。


作者簡介:王旭,螞蟻金服系統部容器和雲原生基礎設施方向的資深技術專家,OpenStack 基金會頂級專案 Kata Containers 的架構委員會創始成員。劉獎,現任職阿里雲作業系統部資深技術專家,負責雲原生底層系統架構設計與實現,長期致力於作業系統技術研發,是國內Linux、OpenSolaris 核心主要貢獻者之一。

“ 阿里巴巴雲原生微信公眾號(ID:Alicloudnative)關注微服務、Serverless、容器、Service Mesh等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐,做最懂雲原生開發者的技術公眾號。”