詳解Docker容器和Docker鏡像

Docker 是現(xiàn)在的開發(fā)人員都已經(jīng)很熟悉的平臺(tái)。它使得我們可以更容易地在容器中創(chuàng)建、部署和運(yùn)行應(yīng)用程序。所需的依賴會(huì)被“打包”并且以進(jìn)程的方式運(yùn)行在主機(jī)操作系統(tǒng)上，而不是像虛擬機(jī)那樣為每個(gè)工作負(fù)載都重復(fù)使用操作系統(tǒng)。這就避免了機(jī)器之間微小的配置差異。

因?yàn)?Docker 使這種方式流行了起來(lái)，所以很多人都在討論 Docker 容器和 Docker 鏡像。實(shí)際上，鏡像和容器并不一定非“Docker”不可，它們可以基于類似的框架。

隨著云原生編程的普及，Docker 本身和 Docker 這種方式也在不斷發(fā)展。云原生這個(gè)術(shù)語(yǔ)有多種定義，但是它主要指的是在云基礎(chǔ)設(shè)施上運(yùn)行應(yīng)用程序，這里所說(shuō)的應(yīng)用程序很可能是基于微服務(wù)架構(gòu)的。它會(huì)使用自動(dòng)化工具，以及云供應(yīng)商的資源和功能。在這種編程風(fēng)格中，像 Docker 這樣的容器化工具通常會(huì)很有用，因?yàn)槿萜鞯膬?nèi)容和搭建過(guò)程會(huì)形成一個(gè)可重復(fù)的環(huán)境，不受底層系統(tǒng)的影響。

如果你正在使用 Docker 的話，你可能也想知道它對(duì)你的應(yīng)用來(lái)講是否足夠安全。和許多系統(tǒng)一樣，我們不能簡(jiǎn)單地用是或者不是來(lái)回答“Docker 是否安全?”這個(gè)問題。以安全的方式使用 Docker 是可以實(shí)現(xiàn)的，但是我們需要考慮采取一些行動(dòng)才行。

在本文中，我們將會(huì)探討 Docker 相關(guān)的最重要的安全因素。

Docker 與 Docker 鏡像

為了解決 Docker 的安全問題，我們需要理解在容器中運(yùn)行鏡像的 Docker 以及 Docker 鏡像本身的差異。

我們會(huì)從一個(gè) Docker 鏡像來(lái)啟動(dòng)容器。Docker 鏡像是一個(gè)分層的結(jié)構(gòu)，我們會(huì)在這里定義要運(yùn)行的進(jìn)程以及運(yùn)行該進(jìn)程所需的文件。例如，如果你是一位 Jakarta EE 開發(fā)人員的話，這可能會(huì)是 Jakarta EE 服務(wù)器的安裝程序以及你的應(yīng)用。

Docker Hub 是一個(gè)存儲(chǔ)庫(kù)，我們可以在這里存儲(chǔ)和共享 Docker 鏡像。我們可以使用這里的鏡像直接啟動(dòng)一個(gè)容器，也可以擴(kuò)展這些鏡像，根據(jù)需要定制化并使用它們。定制化鏡像的方式，也就是選擇要包含哪些二進(jìn)制文件以及它們的權(quán)限，這會(huì)對(duì)應(yīng)用程序的安全性產(chǎn)生影響。

隨后，我們要有一個(gè)實(shí)際運(yùn)行容器的程序。它會(huì)有一個(gè)守護(hù)進(jìn)程(不受用戶直接控制的后臺(tái)進(jìn)程)，負(fù)責(zé)托管鏡像、容器、網(wǎng)絡(luò)和存儲(chǔ)卷。這可能是 Docker Engine，也可能是其他的實(shí)現(xiàn)。它會(huì)負(fù)責(zé)以隔離的方式運(yùn)行你的進(jìn)程。如何運(yùn)行容器也會(huì)對(duì)安全性產(chǎn)生影響。

鏡像的安全考慮因素

我們所構(gòu)建的容器鏡像符合開放容器倡議(Open Container Initiative，OCI)，它不一定要提供開箱即用的全面安全性。我們可以采取一些步驟確保這個(gè)進(jìn)程在容器和主機(jī)系統(tǒng)中是相當(dāng)安全的。

在容器中運(yùn)行這個(gè)進(jìn)程的主要問題在于當(dāng)應(yīng)用被人“入侵”時(shí)，它可以通過(guò)底層主機(jī)獲取權(quán)限，從而對(duì)許多系統(tǒng)帶來(lái)安全風(fēng)險(xiǎn)。

當(dāng)在容器中運(yùn)行時(shí)，我們需要更加警惕安全相關(guān)的問題，因?yàn)榕c虛擬機(jī)相比，容器與主機(jī)有著更緊密的集成(正如前文所述，它運(yùn)行在主機(jī)的操作系統(tǒng)中)。當(dāng)安全漏洞在容器中出現(xiàn)時(shí)，它會(huì)更加嚴(yán)重。這是因?yàn)?，?dāng)應(yīng)用程序在不同的物理機(jī)上運(yùn)行時(shí)，它們?cè)谝欢ǔ潭壬鲜窍嗷シ蛛x的。但是，當(dāng)容器軟件中出現(xiàn)漏洞時(shí)，某個(gè)應(yīng)用 / 進(jìn)程有可能會(huì)訪問另外一個(gè)容器，因此會(huì)訪問自己的漏洞或者將自己的漏洞對(duì)外暴露出去。

對(duì)于容器中的應(yīng)用程序或進(jìn)程，我們應(yīng)該采取的一個(gè)預(yù)防措施就是，它絕不應(yīng)該以“root”用戶身份運(yùn)行。如果作為 root 用戶運(yùn)行的話，該進(jìn)程會(huì)有更多的權(quán)限，因此可以訪問更多低層級(jí)的資源進(jìn)程。我們始終應(yīng)該在容器腳本的某個(gè)地方聲明運(yùn)行主進(jìn)程的用戶：

USERmyuser

理想情況下，進(jìn)程和應(yīng)用程序的所有二進(jìn)制文件其擁有者都應(yīng)該是 root，但是運(yùn)行進(jìn)程的用戶只應(yīng)該有讀取和執(zhí)行的權(quán)限。通過(guò)這種方式，進(jìn)程本身無(wú)法修改容器中構(gòu)成應(yīng)用程序的二進(jìn)制文件和腳本，因此在出現(xiàn)漏洞時(shí)，情況也不會(huì)太嚴(yán)重。

上述的場(chǎng)景就是最小權(quán)限原則的具體實(shí)施：強(qiáng)制代碼以盡可能低的權(quán)限運(yùn)行。當(dāng)進(jìn)程沒有權(quán)限的時(shí)候，它也就不會(huì)被濫用了。另外一個(gè)原則就是減少潛在的攻擊面。鏡像不應(yīng)該包含非嚴(yán)格需要的二進(jìn)制文件，它們可能會(huì)成為安全漏洞的來(lái)源。

所以，鏡像中只應(yīng)包含絕對(duì)必要的二進(jìn)制文件。如果可能的話，從一個(gè)“空白(scratch)”鏡像開始，并且只添加那些所需的二進(jìn)制文件?；蛘撸部梢詮囊粋€(gè)很小的鏡像開始，比如 Alpine 鏡像。二進(jìn)制文件和可執(zhí)行文件越少，出現(xiàn)安全漏洞的幾率就會(huì)越低。

要?jiǎng)h除鏡像中不必要的組成部分，還有第三個(gè)方案，那就是使用多階段構(gòu)建，如果使用“鏡像”本身來(lái)構(gòu)建需要在容器中運(yùn)行的最終的應(yīng)用程序，尤其需要這樣做，所有額外的步驟都可以在一個(gè)單獨(dú)的階段中完成。這樣我們只能在層中將鏡像組織起來(lái)，但是我們?cè)谶\(yùn)行時(shí)能夠?qū)⒉槐匾乃袞|西移除掉。

#Buildstage
#
FROMmaven:3.6.0-jdk-11-slimASbuild
COPYsrc/home/app/src
COPYpom.xml/home/app
RUNmvn-f/home/app/pom.xmlcleanpackage
#
#Packagestage
#
FROMpayara/micro:5.2021.10-jdk11
COPY--from=build/home/app/target/hello.war${DEPLOY_DIR}

上述的多階段構(gòu)建展示了一個(gè)樣例，那就是在最終鏡像中只保留需要的文件和進(jìn)程。在最終的鏡像中，源碼和 maven 工具沒有任何用處，我們只需要 web 應(yīng)用程序的 war 文件。通過(guò)使用兩個(gè)獨(dú)立的階段，我們能夠確保運(yùn)行時(shí)不會(huì)包含不必要的東西。圍繞進(jìn)程和應(yīng)用程序我們應(yīng)該使用相同的方法，即便它們可能是某些標(biāo)準(zhǔn)鏡像的一部分。如果可能的話，我們應(yīng)該從一個(gè)基礎(chǔ)鏡像開始，并添加真正需要的東西。

容器運(yùn)行時(shí)的安全考慮因素

運(yùn)行鏡像的方式和使用的軟件也可能導(dǎo)致安全漏洞。

我們已經(jīng)說(shuō)過(guò)，不應(yīng)該使用 root 用戶在容器中運(yùn)行進(jìn)程。但是，在啟動(dòng)容器的時(shí)候，我們依然可以指定它以特權(quán)方式(privileged)運(yùn)行。通過(guò)該標(biāo)記，我們能夠把所有的能力交給容器，同時(shí)也解除了設(shè)備 cgroup 控制器所強(qiáng)制要求的所有限制。因此在出現(xiàn)安全問題時(shí)，它的影響會(huì)更大。

容器應(yīng)該運(yùn)行在一個(gè)“沙箱”中，所以它們能夠與主機(jī)以及其他正在運(yùn)行的容器進(jìn)行隔離。這個(gè)特權(quán)標(biāo)記會(huì)移除沙箱，因此永遠(yuǎn)都不應(yīng)該使用它。另外，還要避免設(shè)置 --net=host 選項(xiàng)，因?yàn)樗部梢杂绊懮诚洹Ｔ撨x項(xiàng)允許容器像 root 進(jìn)程那樣打開一些數(shù)值較低的端口，這可能會(huì)影響到隔離性。

運(yùn)行容器時(shí)，如果使用主機(jī)網(wǎng)絡(luò)選項(xiàng)的話，端口映射不會(huì)生效，也沒有主機(jī)網(wǎng)絡(luò)的隔離。容器會(huì)使用與主機(jī)相同的網(wǎng)絡(luò)資源。數(shù)值范圍較低的端口一般會(huì)被認(rèn)為是眾所周知的端口，通常只有超級(jí)用戶進(jìn)程才會(huì)連接到這些端口，因此人們?cè)谶B接這樣的端口時(shí)可能不太注意。但容器進(jìn)程也可以訪問整個(gè)網(wǎng)絡(luò)棧，并可能對(duì)其他熟知的端口進(jìn)行掃描。這些端口可能無(wú)法從外部訪問，但可以在容器的進(jìn)程內(nèi)進(jìn)行輪詢，因?yàn)槿萜魇褂玫氖侵鳈C(jī)的網(wǎng)絡(luò)。

Docker 運(yùn)行時(shí)不是唯一可以使用 Docker 鏡像來(lái)啟動(dòng)容器的程序。如前所述，Docker 是使容器流行起來(lái)的工具，由于它是第一個(gè)實(shí)現(xiàn)，所以，多年以來(lái)人們對(duì)這樣一個(gè)容器運(yùn)行時(shí)應(yīng)該如何操作有了很多的了解。隨著 Kubernetes 中容器運(yùn)行時(shí)接口(Container Runtime Interface，CRI)的定義，出現(xiàn)了其他遵循 CRI 的更好、更安全的實(shí)現(xiàn)。

如今，containerd 和 CRI-O 運(yùn)行時(shí)也可以用來(lái)運(yùn)行基于 Docker 鏡像的容器。這些實(shí)現(xiàn)方案刪掉了一些二進(jìn)制文件和進(jìn)程，從而使它們更精簡(jiǎn)、更快速、更安全。例如，它們并不像 dockerd(Docker 運(yùn)行時(shí)進(jìn)程的名稱)那樣，默認(rèn)將 SSH 訪問包含到運(yùn)行中的容器里面。由于攻擊面較小，所以可能出現(xiàn)的問題也會(huì)比較少。

但是，即便有了這些較新的二進(jìn)制文件，安全風(fēng)險(xiǎn)仍然不是零。因此，建議根據(jù)你的進(jìn)程來(lái)定制安全。有一個(gè)與容器相關(guān)的默認(rèn)安全配置文件，但是我們可以通過(guò) AppArmor Linux 安全模塊對(duì)其進(jìn)行微調(diào)。你可以定義諸如文件夾訪問、網(wǎng)絡(luò)訪問以及讀取、允許(或拒絕)寫入或執(zhí)行文件的權(quán)限等能力。在 AppArmor 文件中定義以下條目，拒絕對(duì) /etc 和 /home 目錄的寫入和列出操作：

deny/etc/**wl,deny/home/**wl,

基于對(duì)容器內(nèi)進(jìn)程要求的理解，你應(yīng)該只開放那些應(yīng)用程序正常運(yùn)行所需的權(quán)限。這個(gè)配置文件可以在我們運(yùn)行一個(gè)容器時(shí)進(jìn)行指定。

dockerrun--security-optapparmor=my_profile

結(jié)論：細(xì)致調(diào)節(jié)以獲得最大的安全性

由于 Docker 鏡像和容器需要在各種情況下使用，你需要根據(jù)具體使用情況對(duì)它們進(jìn)行調(diào)整。安全的一般準(zhǔn)則依然能夠指導(dǎo)我們針對(duì)具體的場(chǎng)景應(yīng)該采取哪些策略。

最低權(quán)限原則說(shuō)的是，我們應(yīng)該在實(shí)現(xiàn)功能的同時(shí)給予盡可能少的權(quán)限，以避免出現(xiàn)安全漏洞。對(duì)于容器化場(chǎng)景，這意味著我們不應(yīng)該用 root 用戶在容器中運(yùn)行主進(jìn)程。我們還應(yīng)該對(duì)文件采取適當(dāng)?shù)臋?quán)限，并使用特定的 AppArmor 配置文件限制訪問。

為了減少攻擊面，我們應(yīng)該只包括場(chǎng)景中所嚴(yán)格需要的東西，使用較新的實(shí)現(xiàn)，如 containerd 和 CRI-O 來(lái)運(yùn)行我們的容器，因?yàn)樗鼈儼ㄝ^少的二進(jìn)制文件和進(jìn)程。

作者簡(jiǎn)介：

Rudy De Busscher 喜歡使用 Jakarta EE 和 MicroProfile 創(chuàng)建網(wǎng)絡(luò)應(yīng)用。作為 Payara Services 的產(chǎn)品經(jīng)理，他撰寫技術(shù)內(nèi)容;為 MicroProfile 實(shí)現(xiàn)貢獻(xiàn)力量并推廣 Payara 平臺(tái)。他經(jīng)常在世界最大的開發(fā)者和 Java 活動(dòng)中發(fā)表演講，包括 JavaLand、ConFoo、jLove 等。他在 IT 行業(yè)活躍了 20 多年，在此期間為客戶創(chuàng)建了許多應(yīng)用程序。他也是一個(gè)開源的忠實(shí)粉絲，并在各種開放源碼項(xiàng)目中提供幫助，如 DeltaSpike、PrimeFaces 和 Apache MyFaces。他熱衷于應(yīng)用安全，你可以經(jīng)常發(fā)現(xiàn)他在討論 OAuth2、OpenID Connect 和 JWT。他維護(hù)著 Octopus 開源項(xiàng)目，并且是 Jakarta EE 安全 API 團(tuán)隊(duì)的成員。

原文標(biāo)題：Docker 足夠安全嗎?

文章出處：【微信公眾號(hào)：馬哥Linux運(yùn)維】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。

審核編輯：湯梓紅