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

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

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

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

Docker 與 Docker 鏡像

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

我們會從一個 Docker 鏡像來啟動容器。Docker 鏡像是一個分層的結構，我們會在這里定義要運行的進程以及運行該進程所需的文件。例如，如果你是一位 Jakarta EE 開發人員的話，這可能會是 Jakarta EE 服務器的安裝程序以及你的應用。

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

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

鏡像的安全考慮因素

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

在容器中運行這個進程的主要問題在于當應用被人“入侵”時，它可以通過底層主機獲取權限，從而對許多系統帶來安全風險。

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

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

USERmyuser

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

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

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

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

#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}

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

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

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

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

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

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

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

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

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

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

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

dockerrun--security-optapparmor=my_profile

結論：細致調節以獲得最大的安全性

由于 Docker 鏡像和容器需要在各種情況下使用，你需要根據具體使用情況對它們進行調整。安全的一般準則依然能夠指導我們針對具體的場景應該采取哪些策略。

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

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

作者簡介：

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

原文標題：Docker 足夠安全嗎?

文章出處：【微信公眾號：馬哥Linux運維】歡迎添加關注!文章轉載請注明出處。

審核編輯：湯梓紅