安全容器綜述

【導讀】容器安全很火，這個詞指什麼？通過什麼手段達到容器安全的效果？本文做了詳細介紹。

最近兩年安全容器非常的火，這篇文章就帶大家來看一下何謂安全容器技術，以及目前主流的安全容器都有哪些，最後還會附上很多有價值的參考鏈接。本文將通過如下的方式進行展開：

  1. 何謂安全容器

  2. 安全容器技術的思路是什麼樣的

  3. 目前的主流安全容器有哪些

1. 何謂安全容器

顯然，安全容器這個詞是自解釋的（self-explaining），而伴隨這個詞的一個更常見的問題是爲什麼容器是不安全的，以至於我們需要安全容器技術。

以 Docker 爲例，我們來看一下容器的運行時是什麼樣的。簡而言之，Docker 技術通過 NameSpace 技術來實現進程間的隔離，使用 CGroup 技術來實現進程的資源使用限制，通過 RootFS 技術來實現統一的容器進程視圖。這裏面的 NameSpace 和 CGroup 都是 Linux 內核提供的技術。容器安全的核心問題就是容器進程都共享同一個宿主機內核，一旦某個進程出現問題就會直接或者間接地影響其他容器進程。比如某個容器進程觸發了操作系統 Panic，那麼這臺宿主機上面的所有進程都將受到影響。不要認爲 Linux 操作系統很健壯，我們可以搜索一下 Linux Kernal 代碼裏面的類似 panic 這種字樣，發現還是有很多情況下會導致內核 panic 的。我們日常使用中感覺不到是因爲 panic 的概率非常小，但是一旦數量上去之前，很小的概率最後導致發生的次數可能都是不容忽視的。

我們知道 Docker Daemon 也是以 Root 權限啓動的，這對於 Linux Kernel 無疑是一個不可忽視的風險。儘管 Docker 在 19.03 版本之後推出了一個實驗性質的特性：容許 Docker Daemon 進程可以以非 Root 權限啓動，從而來提供 Docker 的隔離性。但是由於其帶來了多餘的性能損耗，實際上也只能在特定的場景下使用。

其次是 Linux Kernel 也不能保證是絕對安全的。像 Linux 這種龐大的系統，我們很難通過一種完備的方法去驗證它的可行性，Linux Kernel 一共提供 300 多個內核調用，基本上每個調用都有可能出現問題。Linus 在 2015 年的 LinuxCon 上面也針對 Linux 系統的安全性說過：

“The only real solution to security is to admit that bugs happen, and then mitigate them by having multiple layers, so if you have a hole in one component, the next layer will catch the issue.”

“Anyone that thinks that we’ll be entirely secure is just not realistic; we’ll always have issues.”

簡單來說，對於系統安全，我們要承認 bug 是客觀存在的，要解決安全問題只能增加隔離層。任何號稱絕對安全的系統都是不現實的（歡迎對號入座）。

這也是目前主流安全容器技術的思路：隔離。

2. 安全容器技術的主流思路

在上一小節的結尾我們提到一句，目前主流安全容器技術的思路就是增加隔離層，只不過在具體的實現上更具隔離層的具體實現分爲如下兩種：

Lightweight virtual matchine 可以認爲是傳統的虛擬機技術的精簡版本，或者說定製版本，典型的以 Kata 爲代表。guest os 是在用戶態模擬出一個 kernel 出來作爲隔離層，以 gVisor 爲代表。

3. 目前主流安全容器介紹

下面介紹一下目前主流的安全容器。

3.1 Kata

相信很多人接觸的第一個安全容器都是 Kata Container，下面簡稱 Kata。

Kata Containers is an open source community working to build a secure container runtime with lightweight virtual machines that feel and perform like containers, but provide stronger workload isolation using hardware virtualization technology as a second layer of defense.

Kata 旨在通過一個輕量的虛擬機來構建安全容器。在 Kata 中的體感和在容器中沒有區別，但是提供了更強的隔離性。

Kata 項目是由 Intel （Clear Container）和 Hyper.sh （RunV）共建，並且在 2017 年進行開源，在 2018 年 4 月份成爲 OpenStack 基金會旗下的七年來第一個頂級開放基礎設施項目。Kata 本質上是一個使用上像容器的輕量級的虛擬機，虛擬機的安全性已經被各大雲產商，比如 AWS、國內各大雲產商證明了。Hyper.sh 目前已經被螞蟻收購，內部衍生版本叫袋鼠安全容器。

3.2 gVisor

gVisor 這個項目是 2018 年發佈的，相信很多人都聽過 gVisor 項目，因爲它有兩個特別明顯的標籤：Google 發佈、Go 語言實現。不可否認，Google 近幾年的開源產品社區都發展的很不錯，比如 Kubernetes。gVisor 的官方定義異常簡短：爲容器分配一個應用內核，其實就是用戶態內核的意思。

gVisor is an application kernel for containers that provides efficient defense-in-depth anywhere.

gVisor is an application kernel, written in Go, that implements a substantial portion of the Linux system call interface. It provides an additional layer of isolation between running applications and the host operating system.

展開來說，gVisor 給每個容器進程提供一個使用 Go 語言實現的獨立內核。這個內核對容器進程提供 Linux 系統調用接口，使容器進程看上去像運行在其他的 Linux Kernal 一樣。怎麼理解 gVisor 提供的這種 “Guest Kernel” 呢？簡單來說就是容器進程的所有內核系統調用都會調用到 gVisor，gVisor 再去調用真正的系統內核。有點像網絡攻擊中的中間人（Man In the Middle）。

gVisor 提供了 Open Container Initiative (OCI) runtime，叫做 runsc。這裏給大家解釋一下 OCI，在 Kata 上一小節，我們提到了 runv，其實和這裏的 runsc 是很類似的，都是一種 OCI runtime 的實現。OCI 是 2015 年由 Docker 和其他幾家容器廠商共同制定的一套開放容器標準（open standards for containers）。容器其實有很多種實現，比如我們最常見的 Docker、rkt 等，爲了避免 Docker 公司瞎搞，其他廠商聯合起來要挾 Docker 公司一起制定了這個標準，只要容器實現了 OCI 規範，那麼我們就認爲它是一個可以運行的容器。

那麼 OCI runtime 又是什麼東西呢？容器技術主要包括兩個部門：鏡像和容器進程。這兩項技術就分別對應 OCI 的兩種規範：runtime spec 和 image spec。也就是說 runtime 的職責就是將滿足 OCI 的鏡像運行爲一個容器。目前社區有非常多的 OCI runtime，包括：

gVisor 提供了 runsc，我們就可以將它和其他容器生態結合起來使用，比如 Docker 和 Kubernetes（1.12 版本引入的 RuntimeClass）。

關於 gVisor 的介紹就到這裏，後面我們再詳訴。

3.3 Firecracker

既然已經說到了安全容器就不得不提 FireCracker。實現十倍超賣的 AWS 的 Serverless 產品函數計算 lambda 的 runtime 使用的就是 FireCracker。相信國內雲廠商也都是使用或者遷移 FireCracker 的路上了。

FireCracker 最早是在 AWS re：invent 2018 上發佈。與其他的安全容器不同的是，Firecracker 是專門爲 Serverless Computing 打造的虛擬化技術。Firecracker 的最大優點是可以在保持虛擬機級別的安全隔離的同時，又能高效地利用系統資源。

Firecracker is an open source virtualization technology that is purpose-built for creating and managing secure, multi-tenant container and function-based services.

Firecracker enables you to deploy workloads in lightweight virtual machines, called microVMs, which provide enhanced security and workload isolation over traditional VMs, while enabling the speed and resource efficiency of containers. Firecracker was developed at Amazon Web Services to improve the customer experience of services like AWS Lambda and AWS Fargate .

Firecracker is a virtual machine monitor (VMM) that uses the Linux Kernel-based Virtual Machine (KVM) to create and manage microVMs. Firecracker has a minimalist design. It excludes unnecessary devices and guest functionality to reduce the memory footprint and attack surface area of each microVM. This improves security, decreases the startup time, and increases hardware utilization. Firecracker currently supports Intel CPUs, with AMD and Arm support in developer preview.

Firecracker 使用的是一種叫做 microVM 的輕量虛擬機技術，相比於傳統的虛擬機技術強化了安全性和隔離性，同時提高了容器的啓動速度和資源使用率。Firecracker 使用 KVM 技術管理 microVM。Firecracker 剔除了一些不必要的內核功能來提高內存的使用率和減少攻擊面，這也是 Firecracker 效率高的核心原因。

最後值得一提的是 Firecracker 是 rust 語言編寫的，star 數已經高達 12k 之多，這個是 github 地址：https://github.com/firecracker-microvm/firecracker

轉自：

legendtkl.com/2020/09/15/secure-container-overview/

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/icSk0J_y_iHjmp0rSGYEOw

猜你喜歡