Docker容器實戰：容器安全性分析
容器是基于操作系統實現的虛擬化，相比于傳統的物理主機和虛擬機，在安全上會面臨更多的風險。對于容器的使用者而言，學習并了解容器的安全相關知識是一項重要的工作。
本文將圍繞容器安全的主旨進行介紹，讀者在閱讀后對于相關方面的應用能有更多理解。
一. 容器的安全威脅
在容器的應用中，最大的安全隱患來自于其與主機共享內核的模式，這是容器能實現輕量化的原因，但也讓其受攻擊的范圍變得更大。
要理解這一點并不難，我們可以將容器與虛擬機來做個對比。
在虛擬機環境，每臺虛擬機都包含了一個獨立的操作系統，可以單獨地完成絕大部分事務處理，而只需要與宿主機之間保留非常少的交互接口即可。這使得它們之間的攻擊面變得非常小，如果黑客要透過虛擬機來攻擊到宿主機，需要先找到Hypervisor層的漏洞并進行攻破才有可能實現。虛擬機具有良好的隔離性，不止能更好防護攻擊，也保證了不會因為虛擬機的崩潰而影響到宿主機。
而在容器的環境中，由于容器只封裝應用和依賴，這使得其必須使用主機的內核來進行運作。因此，只要獲取到容器的權限即可實現對內核的訪問，包括攻擊。如果容器中的應用導致內核崩潰，那么整個主機系統也會跟著一起崩塌。
在了解完容器的弱點之后，我們再來看下容器在使用中會面臨哪些安全威脅：
1、鏡像污染
目前，Docker Hub上面有著數量眾多的第三方上傳鏡像，這些鏡像質量參差不齊。在這其中，不排除有黑客故意上傳包含了惡意程序的鏡像，并偽裝成業務鏡像供用戶下載使用。當用戶誤用此類鏡像啟動容器時，無疑會導致容器被入侵。因此，用戶必須保證容器所使用的鏡像是可受信任的，盡可能不使用非信任的第三方鏡像。
2、網絡攻擊
Docker默認使用bridge網絡，該網絡會創建一個虛擬網橋，連接在同一個網橋之間的容器可以互相訪問。當某個容器被入侵時，黑客有可能順著網絡訪問到宿主機中的其他容器。同時 ，攻擊者也可以通過DDos等方式，攻擊容器的服務來耗盡主機的資源，從而引起整個宿主機的崩潰。
3、內核攻擊
當黑客獲取到容器權限時，由于共享內核的緣故，理論上可通過對內核的攻擊來達到控制或影響主機的地步 。例如，Linux內核3.16以前的版本存在一個內存溢出漏洞CVE-2014-7822，由于splice系統調用在兩個文件間拷貝數據時未檢查拷貝大小，可溢出覆寫內核數據。因此，本地未授權用戶可利用此漏洞越界寫內存，導致系統崩潰。
4、操作不當
用戶在配置容器時，由于某些錯誤操作可能會將主機置于危險的境地。如：在啟動容器時將主機的根目錄映射到容器中，那么理論上容器就可以對主機的文件系統進行任意修改，造成極大的安全風險。
$ docker run -d -v /:/host nginx
又或者在啟用容器時使用特權模式(--privileged)，此時Docker容器被允許可以訪問主機上的所有設備，并可以獲取大量設備文件的訪問權限。
$ docker run -d --privileged nginx
5、針對Docker Daemon的攻擊
Docker使用的是C/S架構，作為服務端的Docker Daemon會接收客戶端通過CLI或者REST API發送的命令，并執行對容器的相應操作。但請求不一定都是由可信任的用戶發起的，攻擊者可能通過偽造請求的方式，來達到欺騙Daemon端執行危險的操作。
6、Docker漏洞攻擊
Docker本身屬于應用程序，不可避免地會有出現代碼的漏洞，這可能導致程序受到攻擊。
例如：在2019年時，Docker被爆出來一個逃逸漏洞CVE-2019-5736。該漏洞導致攻擊者可以通過特定的容器鏡像或者exec操作獲取到宿主機runc執行文件時的文件句柄，并修改掉runc的二進制文件，最終獲取到宿主機的root執行權限。
二、 Docker的安全防護
針對容器在安全方面存在的威脅，Docker社區也使用了不少安全措施來進行應對，以便能夠讓用戶更安全地使用容器。
下面是Docke在安全上的主要防護策略：
1、 Namespace
Namespace即命名空間，也被稱為名稱空間，這是Linux提供的一種內核級別的環境隔離功能，它的主要用途是對容器提供資源的訪問隔離。Docker充分利用了Namespace的技術，使其達到盡可能地隔離容器之間以及對宿主機的影響。
目前Namespace支持多種資源的隔離，包括文件系統掛載 、主機名和域名、進程間通信 、進程訪問、網絡隔離、用戶和組隔離等。
2、Cgroup
Cgroup全稱為Control Group( 控制組），它也是Docker容器的重要特性。如果說Namespace是用于隔離，那么Cgroup則是限制容器對于資源的占用，如CPU、內存、磁盤/IO等。這個特性非常有用，它避免了某個容器因為被Ddos攻擊或者自身程序的問題導致對資源的不斷占用，并最終影響到宿主機及上面運行的其他容器，出現“雪崩”的災難 。
3、Capability
Capability是Linux內核具有的一個強大特性，可以提供顆粒化的權限訪問控制。默認情況下，Docker啟動的容器對能力有嚴格限制，只允許使用內核的一部分能力，包括chown、net_bind_service、fowner、kill、setgid等。
事實上，在大部分情況下程序并不需要真正的root權限，容器只需要具備少數的能力即可。對于能力的顆粒化劃分，能保證即使容器被入侵后，也無法獲取本地的較高權限，可以進行的破壞有限。
另外，用戶可以通過--cap-add和--cap-drop這兩個參數來修改能力。如下面的例子，我們將容器的chown 能力去掉后，在容器里就無法改變文件的所有者了。
$ docker run -it --cap-drop=chown centos
[root@65a55b893d3b /]# touch /root/1.txt
[root@65a55b893d3b /]# ls -l /root/1.txt
-rw-r--r--. 1 root root 0 Jul 3 11:33 /root/1.txt
[root@65a55b893d3b /]# chown daemon /root/1.txt
chown: changing ownership of '/root/1.txt': Operation not permitted
4、Docker Daemon安全防護
Docker社區希望實現由非root權限來啟動Docker Daemon，這對于Docker的安全性是一種較大的強化。但要解決這個問題面臨著不小的困難，因為創建容器需要執行很多特權操作，如掛載文件系統、配置網絡等。在19.03版本中Rootless模式作為實驗性功能推出，并在20.10版本中畢業。該功能對于使用會有較多限制，如不支持overlay網絡，AppArmor特性等。同時該模式對內核版本要求高，如果要使用默認的overlay2 存儲驅動，需要至少5.11的內核版本。
同時，為了加強對服務端的保護，Docker的REST API（客戶端用來與服務端通信的接口）在0.5.2之后，由原先綁定在127.0.0.1上的TCP套接字改為使用本地Unix套接字機制代替，因為前者更容易受到跨站請求偽造攻擊。
$ netstat -lnpx
Active UNIX domain sockets (only servers)
Proto RefCnt Flags Type State I-Node PID/Program name Path
unix G2 [ ACC ] STREAM LISTENING 644610 1/systemd /var/run/docker.sock
......
5、其他安全機制
除了上面介紹的安全機制外，Docker還支持結合現有的安全軟件或機制來增強自身的安全性，例如：AppArmor、SELinux、Seccomp等。
AppArmor和SElinux屬于MAC (Mandatory Access Control）系統，AppArmor主要內置在Ubuntu、Debian等操作系統，而SELinux則預裝在Redhat、Centos中。MAC系統可以通過定制化的安全策略來控制進程對于資源的訪問。目前，在支持SElinux的系統上，Docker的SElinux使用不是默認打開 的，需要在啟動Docker daemon時加上--selinux-enabled=true參數。而在支持AppArmor的系統上，對于Docker的安全防護功能是默認打開的。
Seccomp（secure computing mode)是一種Linux內核提供的安全特性，它可以用來限制容器的可執行操作。Seccomp以白名單或黑名單的方式限制進程進行系統調用，通過禁止進程調用不必要的系統功能來減少內核暴露的接口數量，從而降低內核的攻擊面。Docker在啟動容器時默認會啟用Seccomp保護，可通過下面命令進行確認。默認的白名單規則僅保留了Linux中比較常見并且安全的系統調用，具有適度的安全性。
$ grep CONFIG_SECCOMP= /boot/config-$(uname -r)
CONFIG_SECCOMP=y
有關更多安全相關的內容，讀者可自行查看Docker官網，在此不過多列舉。
總結：
雖然容器面臨著不少安全威脅，但用戶并不需要為此過多擔憂。就如本文所述，Docker在安全方面已經有著非常多的應對措施，可以很好地保證容器的安全性和可靠性。
目前，Docker作為生產環境的容器化產品，已在各大企業中被廣泛使用。
