雲原生是一座由精妙理論所構築的摩天大廈,但其中的磚石還需加固。
當雲原生將容器技術做爲下一代雲計算的基礎之一時,並不意味着容器自己中止了演化。事實上,以 Docker 爲表明的傳統容器在遇到多租戶場景時,它的安全問題馬上暴露了出來,這時,人們才懷念起虛擬化的好處。
因而,採用虛擬化技術的「安全容器」這一律念應運而生,而開啓這一變革的,正是 Kata Containers,前不久,它剛剛度過兩週年。
新的 Kata Containers 爲咱們帶來虛擬機的安全性和隔離性、與容器兼容的 API 接口,同時還有與容器同一級別的性能,這意味着採用安全容器的時機已經成熟。
與此相對的是,上個月,Docker 的企業級業務被打包出售,據稱出售價格甚至不及幾輪下來的融資總額。
全部在生產環境使用容器的公司,從如今開始都有必要審視本身的安全策略,並制定從容器到安全容器的遷移計劃。
這一切是怎麼發生的呢?聽我爲你一一道來。
<strong>Docker 的潰敗</strong>
2019 年 11 月 13 日,私有云基礎設施公司 Mirantis 在其官方博客宣佈,收購 Docker 公司企業級業務,包括接管它的 700 多個客戶,這標誌着 Docker 公司從 2013 年開始的商業化探索完全失敗。
在不瞭解容器發展歷史的人看來,這種結果很難理解,Docker 是容器熱潮的開創者,容器則是這一輪雲計算技術演進的開啓者,爲何明明站在風口上了,卻仍然飛不起來?
這與 Docker 創始人的一系列迷之操做當然脫不了干係,但其實,Docker 今天的命運,在 4 年前就決定了。
在 2013 年之前,業界其實一直都沒有找到雲計算原生的打開方式,GAE 以及 Cloud Foundry 早期版本爲表明的 PaaS 將你們都帶到坑裏,只留下一地雞毛。直到 Docker 開源,你們才如夢方醒,原來不是方向不對,而是應用分發和交付的手段不行。
然而,Docker 公司將其核心代碼開源的初心並不僅是造福業界,它是想用這種方式吸引商業客戶。Docker 公司將 Docker 註冊爲商標,引發了社區的警覺,各類自創容器項目層出不窮。
爲告終束這種亂象,2015 年 6 月,容器開放推動組織 OCI 成立,旨在圍繞容器格式和運行時制定一個開放的標準,Docker 做爲創始成員,意圖將這個標準制定權抓在手裏。
然而,你們實在是被 Docker 在商業化和社區兩邊左右搖擺的態度嚇怕了,2014 年 Kubernetes 發佈後,迅速吸引了包括紅帽在內的一批成員,並在短短一年以後的 2015 年 7 月,Kubernetes 發佈了 1.0 版本,隨之而來的還有 CNCF 雲原生計算基金會。
CNCF 的誕生宣告雲計算技術演進的重心從容器轉移到容器編排,隨後的 2016 年,Kubernetes 發佈了容器運行時接口 CRI,只要符合這個接口,Kubernetes 就能夠經過它來運行容器,是否是 Docker 已經可有可無了。
就這樣,容器從 Docker 變成了一種標準接口實現,只要符合這個標準,不用管背後運行的是什麼。
結合容器和 Kubernetes,你們在本身的集羣上用得很愉快,但當雲廠商試圖向大衆提供容器服務時,多租戶安全問題出現了。
<strong>AWS 的選擇</strong>
要理解這個問題,咱們首先要了解容器的原理。
Linux 容器的本質是一種進程隔離技術,經過 cgroup 和 namespace,容器裏的應用只使用給定的資源,不一樣容器之間互不侵犯。
從容器裏應用的角度來看,它只能看到給定的計算存儲資源和爲其定製的系統,但從容器外面的系統來看,它運行的是一個一個的進程。
若是這些容器都屬於同一個用戶那還沒什麼,但若是是雲服務,一臺機器裏面運行着不一樣用戶的一個個進程,光是想想就有一種四處漏風的感受!
從技術角度講,AWS 在它的官方博客中是這麼描述這個安全隱患的:
因爲操做系統內核漏洞,Docker 組件設計缺陷,以及不當的配置都會致使 Docker 容器發生逃逸,從而獲取宿主機權限。因爲頻發的安全及逃逸漏洞,在公有云環境容器應用不得不也運行在虛擬機中,從而知足多租戶安全隔離要求。而分配、管理、運維這些傳統虛擬機與容器輕量、靈活、彈性的初衷背道而馳,同時在資源利用率、運行效率上也存浪費。
這就是雲原生裏面的多租戶問題,其本質是容器安全問題。前幾年,雲廠商在推出 Kubernetes 集羣服務方面進展神速,但在提供單一容器託管方面卻步伐遲緩,就是由於這個問題遲遲沒有解決。
而且,多租戶問題不只僅在公有云上存在,在公司內部的私有云上一樣存在,不一樣部門、團隊的應用,理應進行強隔離,以避免一個業務出現問題影響整個公司。但過去,你們應用容器的勢頭很強,裝做看不到這個問題罷了。
對於多租戶問題,雖然社區逐漸有了一些解決方案,但由於還不太成熟,也缺少一個標誌性事件把它們推到前臺。終於,2018 年 12 月,AWS 出手了。
衆所周知,AWS 是雲計算行業的領頭羊,但在容器到雲原生這波浪潮裏,AWS 卻變成了跟隨者的角色,它確定是不甘心的,最終,它在容器安全給出了本身的答案,從新走在了全部雲廠商的前面。
AWS 的答案是<strong>Firecracker</strong>,一種輕量級虛擬機(MicroVM),這個輕量級是相對於全功能虛擬機來講的,後者的表明是 QEMU,號稱能模擬全部硬件設備。Firecracker 將能省的地方都省了,最終留下一個極其精巧的運行時,只保護該保護的地方。
從性能上來說,Firecracker 和容器已經很接近了,它最初的意圖就是爲 AWS 的 Serverless 服務 Lambda 提供保護,性能必需要跟上;從安全上來說,在該保護的地方,它提供的是虛擬機級別的保護,不管是來自內部和外部的漏洞和***都能防禦。
AWS 還推出了 Firecracker 的 containerd 實現,這意味着能夠用標準容器的方法來驅動 Firecracker,說明用虛擬機來解決容器安全這條道路是可行的。
可是,AWS 有本身的一套完整生態,Firecracker 也是這個生態的一部分,雖然它開源了,社區並不能作到開箱即用,與 Kubernetes 有一些不兼容的地方。
這時,就輪到 Kata Containers 出場了。
<strong>面向雲原生的虛擬化</strong>
Kata Containers 的前身是 Hyper runV 和 Intel Clear Container,這二者都試圖用虛擬化的技術來解決容器安全問題。
二者都是 2015 年 5 月布的,後來發現彼此技術路徑差很少,兩邊的創始人聚到一塊兒一合計,要不合並吧,因而 Kata Containers 就誕生了。
當時,正遭遇 Kubernetes 和 CNCF 強勁攻勢的 OpenStack 基金會,一眼看出了 Kata Containers 的應用潛力,因而在將戰略改成面向開放基礎設施的同時,將 Kata Containers 接納爲第二個頂級開放基礎設施項目,與 OpenStack 同級。
可是,Kata Containers 在誕生後一段時間裏,卻<strong>並不受社區的開發人員看好</strong>。
其重要緣由有二,第一個是,Kata 雖然從第一天就將與 Kubernetes 集成做爲最優先目標,但 Kubernetes 早期版本只考慮瞭如何運行容器,要讓 Kubernetes 支持非容器技術須要額外作一些功夫,當時 runC 容器還如日中天,讓 Kubernetes 管理虛擬機是一個比較另類的作法。
第二,Kata 雖然成功地讓虛擬機兼容了容器的大部分接口,可是性能太差,其中一個主要緣由在於,它在底層採用了上面提到的 QEMU 做爲對接系統接口層,而 QEMU 是一個包含數百萬行代碼、數萬個文件的項目,雖然 Kata 努力對其進行了精簡,但帶來額外的性能損耗,仍是讓對安全不太敏感的應用難以接受。
事情的起色就在於 AWS Firecracker 的發佈,當時,Firecracker 只支持 AWS 本身的 Serverless 服務,可是明眼人都看得出來,Serverless 都支持了,容器還遠嗎?Firecracker 也讓你們更加關注容器安全問題,Kata Containers 開始受到更多的關注。
同時,Kata 也在利用包括 Firecracker 在內的最新開源社區進展,進一步下降開銷:好比,支持 Firecracker 做爲部分適用場景的 VMM,以及研發本身的 rust-VMM cloud-hypervisor,又將沙箱 agent 替換爲輕量的 rust-agent,讓內存佔用從十多 MB 下降到 1.1MB,提高肉眼可見,而且,這個開銷已經能夠接受。
另外一方面,在 Kata Containers 和社區的推進下,Kubernetes 開始接受安全容器了,在 Kubernetes 裏運行 Kata 再也不須要作額外處理。
在 Kata Containers 的兩週年之際,它給本身的定義是<strong>面向雲原生的虛擬化</strong>。
之因此要強調虛擬化,是由於它的本質是用的虛擬化技術,但與傳統虛擬化相比,Kata Containers 走的是一個徹底不一樣的發展方向,是適合雲原生場景下的虛擬化。
可是爲何又叫它安全容器呢?如今回到咱們開頭介紹的多租戶問題,使用 Kata Containers 後,當你啓動一個容器,其實是啓動了一個虛擬機,但這個虛擬機的功能、生命週期、性能表現都和容器如出一轍。
<strong>鴨子測試</strong>說,若是一個動物走路像鴨子、說話像鴨子、長得像鴨子、啄食也像鴨子,那麼咱們就認爲它是一隻鴨子。放到 Kata Containers 也同樣。
Docker 自身的技術路線,沒法很好地解決安全問題,因此當 CRI 和安全容器出現以後,它的商業化探索已經註定不會有太好結局。
<strong>Kata Containers 與安全容器的將來</strong>
軟件世界裏有不少不肯定性,但咱們能夠肯定的是,安全問題必定會發生。
那麼,如何應對安全問題呢?Linus 說過這樣一句話:
安全問題的惟一正解在於容許那些(致使安全問題的)Bug 發生,但經過額外的隔離層來阻擋住它們。
—— LinuxCon NA 2015, Linus Torvalds
要一勞永逸地解決容器安全問題,可能惟有爲其添加額外的隔離層,這也是 Kata Containers 的思路。
值得一提的是,安全容器<strong>並非只有 Kata Containers 和 Firecracker</strong>這一條路線,Google 推出的 gVisor 是另外一條路線,它是一個更純粹的隔離層,上層應用對系統的全部訪問都通過隔離層處理後,再將其中少數請求交給宿主機響應。
Kata Containers 通過兩年耕耘,業界開始逐漸跟進,好比百度智能雲,在函數計算、容器服務、邊緣計算等方面開始嘗試。
2019 年,Kata Containers 創始人加入螞蟻金服,螞蟻並未干涉 Kata Containers 的發展路線,Kata 還是社區主導的開源項目,Kata Containers 也開始在螞蟻和阿里內部逐漸落地。
Kata Containers 將來仍會繼續優化其性能,固然,更重要的是,容器和虛擬機就像是一座天平的兩端,Kata Containers 須要不斷地摸索,去找到那個平衡點。
AWS 已經證實了安全容器是公有云落地 Serverless 的關鍵技術之一,與之相似,邊緣計算也將成爲安全容器的典型應用場景。
隨着 AWS 以及各家雲廠商的跟進,能夠預見,2020 年將迎來安全容器落地的爆發。
<strong>Kata Containers 項目地址:</strong>
<a href="https://github.com/kata-containers" target="_blank">https://github.com/kata-containers</a>;git