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

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

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

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

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

Docker 與 Docker 鏡像

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

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

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

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

鏡像的安全考慮因素

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

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

當(dāng)在容器中運行時，我們需要更加警惕安全相關(guān)的問題，因為與虛擬機(jī)相比，容器與主機(jī)有著更緊密的集成（正如前文所述，它運行在主機(jī)的操作系統(tǒng)中）。當(dāng)安全漏洞在容器中出現(xiàn)時，它會更加嚴(yán)重。這是因為，當(dāng)應(yīng)用程序在不同的物理機(jī)上運行時，它們在一定程度上是相互分離的。但是，當(dāng)容器軟件中出現(xiàn)漏洞時，某個應(yīng)用 / 進(jìn)程有可能會訪問另外一個容器，因此會訪問自己的漏洞或者將自己的漏洞對外暴露出去。

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

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

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

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

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

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

容器運行時的安全考慮因素

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

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

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

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

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

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

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

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

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

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

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

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

作者簡介：

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

原文鏈接：https://www.infoq.com/articles/securing-docker/

文章轉(zhuǎn)載：InfoQ

（版權(quán)歸原作者所有，侵刪）