docker容器實(shí)戰(zhàn)：容器安全性分析

作者：運(yùn)維老兵Alex 2022-07-18 11:13:07

云計(jì)算

云原生 本文將圍繞容器安全的主旨進(jìn)行介紹，讀者在閱讀后對于相關(guān)方面的應(yīng)用能有更多理解。

站在用戶的角度思考問題，與客戶深入溝通，找到達(dá)日網(wǎng)站設(shè)計(jì)與達(dá)日網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗(yàn)，讓設(shè)計(jì)與互聯(lián)網(wǎng)技術(shù)結(jié)合，創(chuàng)造個性化、用戶體驗(yàn)好的作品，建站類型包括：做網(wǎng)站、成都網(wǎng)站制作、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣、空間域名、雅安服務(wù)器托管、企業(yè)郵箱。業(yè)務(wù)覆蓋達(dá)日地區(qū)。

成都網(wǎng)站建設(shè)公司創(chuàng)新互聯(lián)科技已有多年成都網(wǎng)站建設(shè)經(jīng)驗(yàn)，專注網(wǎng)站建設(shè)，網(wǎng)站設(shè)計(jì)，為眾多單位提供網(wǎng)站建設(shè)、網(wǎng)站設(shè)計(jì)服務(wù)，有關(guān)企業(yè)網(wǎng)站制作方案、改版、費(fèi)用等問題，請聯(lián)系成都創(chuàng)新互聯(lián)建站。

容器是基于操作系統(tǒng)實(shí)現(xiàn)的虛擬化，相比于傳統(tǒng)的物理主機(jī)和虛擬機(jī)，在安全上會面臨更多的風(fēng)險(xiǎn)。對于容器的使用者而言，學(xué)習(xí)并了解容器的安全相關(guān)知識是一項(xiàng)重要的工作。

本文將圍繞容器安全的主旨進(jìn)行介紹，讀者在閱讀后對于相關(guān)方面的應(yīng)用能有更多理解。

一. 容器的安全威脅

在容器的應(yīng)用中，最大的安全隱患來自于其與主機(jī)共享內(nèi)核的模式，這是容器能實(shí)現(xiàn)輕量化的原因，但也讓其受攻擊的范圍變得更大。

要理解這一點(diǎn)并不難，我們可以將容器與虛擬機(jī)來做個對比。

在虛擬機(jī)環(huán)境，每臺虛擬機(jī)都包含了一個獨(dú)立的操作系統(tǒng)，可以單獨(dú)地完成絕大部分事務(wù)處理，而只需要與宿主機(jī)之間保留非常少的交互接口即可。這使得它們之間的攻擊面變得非常小，如果黑客要透過虛擬機(jī)來攻擊到宿主機(jī)，需要先找到Hypervisor層的漏洞并進(jìn)行攻破才有可能實(shí)現(xiàn)。虛擬機(jī)具有良好的隔離性，不止能更好防護(hù)攻擊，也保證了不會因?yàn)樘摂M機(jī)的崩潰而影響到宿主機(jī)。

而在容器的環(huán)境中，由于容器只封裝應(yīng)用和依賴，這使得其必須使用主機(jī)的內(nèi)核來進(jìn)行運(yùn)作。因此，只要獲取到容器的權(quán)限即可實(shí)現(xiàn)對內(nèi)核的訪問，包括攻擊。如果容器中的應(yīng)用導(dǎo)致內(nèi)核崩潰，那么整個主機(jī)系統(tǒng)也會跟著一起崩塌。

在了解完容器的弱點(diǎn)之后，我們再來看下容器在使用中會面臨哪些安全威脅：

1、鏡像污染

目前，Docker Hub上面有著數(shù)量眾多的第三方上傳鏡像，這些鏡像質(zhì)量參差不齊。在這其中，不排除有黑客故意上傳包含了惡意程序的鏡像，并偽裝成業(yè)務(wù)鏡像供用戶下載使用。當(dāng)用戶誤用此類鏡像啟動容器時，無疑會導(dǎo)致容器被入侵。因此，用戶必須保證容器所使用的鏡像是可受信任的，盡可能不使用非信任的第三方鏡像。

2、網(wǎng)絡(luò)攻擊 

Docker默認(rèn)使用bridge網(wǎng)絡(luò)，該網(wǎng)絡(luò)會創(chuàng)建一個虛擬網(wǎng)橋，連接在同一個網(wǎng)橋之間的容器可以互相訪問。當(dāng)某個容器被入侵時，黑客有可能順著網(wǎng)絡(luò)訪問到宿主機(jī)中的其他容器。同時 ，攻擊者也可以通過DDos等方式，攻擊容器的服務(wù)來耗盡主機(jī)的資源，從而引起整個宿主機(jī)的崩潰。

3、內(nèi)核攻擊

當(dāng)黑客獲取到容器權(quán)限時，由于共享內(nèi)核的緣故，理論上可通過對內(nèi)核的攻擊來達(dá)到控制或影響主機(jī)的地步 。例如，Linux內(nèi)核3.16以前的版本存在一個內(nèi)存溢出漏洞CVE-2014-7822，由于splice系統(tǒng)調(diào)用在兩個文件間拷貝數(shù)據(jù)時未檢查拷貝大小，可溢出覆寫內(nèi)核數(shù)據(jù)。因此，本地未授權(quán)用戶可利用此漏洞越界寫內(nèi)存，導(dǎo)致系統(tǒng)崩潰。

4、操作不當(dāng)

用戶在配置容器時，由于某些錯誤操作可能會將主機(jī)置于危險(xiǎn)的境地。如：在啟動容器時將主機(jī)的根目錄映射到容器中，那么理論上容器就可以對主機(jī)的文件系統(tǒng)進(jìn)行任意修改，造成極大的安全風(fēng)險(xiǎn)。

$ docker run -d -v /:/host nginx

又或者在啟用容器時使用特權(quán)模式(--privileged)，此時Docker容器被允許可以訪問主機(jī)上的所有設(shè)備，并可以獲取大量設(shè)備文件的訪問權(quán)限。

$ docker run -d --privileged nginx

5、針對Docker  Daemon的攻擊

Docker使用的是C/S架構(gòu)，作為服務(wù)端的Docker Daemon會接收客戶端通過CLI或者REST API發(fā)送的命令，并執(zhí)行對容器的相應(yīng)操作。但請求不一定都是由可信任的用戶發(fā)起的，攻擊者可能通過偽造請求的方式，來達(dá)到欺騙Daemon端執(zhí)行危險(xiǎn)的操作。

6、Docker漏洞攻擊

Docker本身屬于應(yīng)用程序，不可避免地會有出現(xiàn)代碼的漏洞，這可能導(dǎo)致程序受到攻擊。

例如：在2019年時，Docker被爆出來一個逃逸漏洞CVE-2019-5736。該漏洞導(dǎo)致攻擊者可以通過特定的容器鏡像或者exec操作獲取到宿主機(jī)runc執(zhí)行文件時的文件句柄，并修改掉runc的二進(jìn)制文件，最終獲取到宿主機(jī)的root執(zhí)行權(quán)限。

二、 Docker的安全防護(hù)

針對容器在安全方面存在的威脅，Docker社區(qū)也使用了不少安全措施來進(jìn)行應(yīng)對，以便能夠讓用戶更安全地使用容器。

下面是Docke在安全上的主要防護(hù)策略：

1、 Namespace

Namespace即命名空間，也被稱為名稱空間，這是Linux提供的一種內(nèi)核級別的環(huán)境隔離功能，它的主要用途是對容器提供資源的訪問隔離。Docker充分利用了Namespace的技術(shù)，使其達(dá)到盡可能地隔離容器之間以及對宿主機(jī)的影響。

目前Namespace支持多種資源的隔離，包括文件系統(tǒng)掛載 、主機(jī)名和域名、進(jìn)程間通信 、進(jìn)程訪問、網(wǎng)絡(luò)隔離、用戶和組隔離等。

2、Cgroup

Cgroup全稱為Control Group( 控制組），它也是Docker容器的重要特性。如果說Namespace是用于隔離，那么Cgroup則是限制容器對于資源的占用，如CPU、內(nèi)存、磁盤/IO等。這個特性非常有用，它避免了某個容器因?yàn)楸籇dos攻擊或者自身程序的問題導(dǎo)致對資源的不斷占用，并最終影響到宿主機(jī)及上面運(yùn)行的其他容器，出現(xiàn)“雪崩”的災(zāi)難 。

3、Capability

Capability是Linux內(nèi)核具有的一個強(qiáng)大特性，可以提供顆粒化的權(quán)限訪問控制。默認(rèn)情況下，Docker啟動的容器對能力有嚴(yán)格限制，只允許使用內(nèi)核的一部分能力，包括chown、net_bind_service、fowner、kill、setgid等。

事實(shí)上，在大部分情況下程序并不需要真正的root權(quán)限，容器只需要具備少數(shù)的能力即可。對于能力的顆?；瘎澐?，能保證即使容器被入侵后，也無法獲取本地的較高權(quán)限，可以進(jìn)行的破壞有限。

另外，用戶可以通過--cap-add和--cap-drop這兩個參數(shù)來修改能力。如下面的例子，我們將容器的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安全防護(hù)

Docker社區(qū)希望實(shí)現(xiàn)由非root權(quán)限來啟動Docker Daemon，這對于Docker的安全性是一種較大的強(qiáng)化。但要解決這個問題面臨著不小的困難，因?yàn)閯?chuàng)建容器需要執(zhí)行很多特權(quán)操作，如掛載文件系統(tǒng)、配置網(wǎng)絡(luò)等。在19.03版本中Rootless模式作為實(shí)驗(yàn)性功能推出，并在20.10版本中畢業(yè)。該功能對于使用會有較多限制，如不支持overlay網(wǎng)絡(luò)，AppArmor特性等。同時該模式對內(nèi)核版本要求高，如果要使用默認(rèn)的overlay2 存儲驅(qū)動，需要至少5.11的內(nèi)核版本。

同時，為了加強(qiáng)對服務(wù)端的保護(hù)，Docker的REST API（客戶端用來與服務(wù)端通信的接口）在0.5.2之后，由原先綁定在127.0.0.1上的TCP套接字改為使用本地Unix套接字機(jī)制代替，因?yàn)榍罢吒菀资艿娇缯菊埱髠卧旃簟?/p>

$ 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、其他安全機(jī)制

除了上面介紹的安全機(jī)制外，Docker還支持結(jié)合現(xiàn)有的安全軟件或機(jī)制來增強(qiáng)自身的安全性，例如：AppArmor、SELinux、Seccomp等。

AppArmor和SElinux屬于MAC (Mandatory Access Control）系統(tǒng)，AppArmor主要內(nèi)置在Ubuntu、Debian等操作系統(tǒng)，而SELinux則預(yù)裝在Redhat、Centos中。MAC系統(tǒng)可以通過定制化的安全策略來控制進(jìn)程對于資源的訪問。目前，在支持SElinux的系統(tǒng)上，Docker的SElinux使用不是默認(rèn)打開 的，需要在啟動Docker daemon時加上--selinux-enabled=true參數(shù)。而在支持AppArmor的系統(tǒng)上，對于Docker的安全防護(hù)功能是默認(rèn)打開的。

Seccomp（secure computing mode)是一種Linux內(nèi)核提供的安全特性，它可以用來限制容器的可執(zhí)行操作。Seccomp以白名單或黑名單的方式限制進(jìn)程進(jìn)行系統(tǒng)調(diào)用，通過禁止進(jìn)程調(diào)用不必要的系統(tǒng)功能來減少內(nèi)核暴露的接口數(shù)量，從而降低內(nèi)核的攻擊面。Docker在啟動容器時默認(rèn)會啟用Seccomp保護(hù)，可通過下面命令進(jìn)行確認(rèn)。默認(rèn)的白名單規(guī)則僅保留了Linux中比較常見并且安全的系統(tǒng)調(diào)用，具有適度的安全性。

$ grep CONFIG_SECCOMP= /boot/config-$(uname -r)
CONFIG_SECCOMP=y

有關(guān)更多安全相關(guān)的內(nèi)容，讀者可自行查看Docker官網(wǎng)，在此不過多列舉。

總結(jié)：

雖然容器面臨著不少安全威脅，但用戶并不需要為此過多擔(dān)憂。就如本文所述，Docker在安全方面已經(jīng)有著非常多的應(yīng)對措施，可以很好地保證容器的安全性和可靠性。

目前，Docker作為生產(chǎn)環(huán)境的容器化產(chǎn)品，已在各大企業(yè)中被廣泛使用。

名稱欄目：Docker容器實(shí)戰(zhàn)：容器安全性分析
新聞來源：http://www.5511xx.com/article/cdscpsh.html