本文介紹了 12 個(gè)優(yōu)化 Docker 鏡像安全性的技巧。每個(gè)技巧都解釋了底層的攻擊載體，以及一個(gè)或多個(gè)緩解方法。這些技巧包括了避免泄露構(gòu)建密鑰、以非 root 用戶(hù)身份運(yùn)行，或如何確保使用最新的依賴(lài)和更新等。

1前言

當(dāng)你是剛開(kāi)始使用 Docker 的新手時(shí)，你很可能會(huì)創(chuàng)建不安全的 Docker 鏡像，使攻擊者很容易借此接管容器，甚至可能接管整個(gè)主機(jī)，然后滲透到你公司的其他基礎(chǔ)設(shè)施中。

可以被濫用來(lái)接管你的系統(tǒng)的攻擊向量有很多，例如：

• 啟動(dòng)的應(yīng)用程序（在你 Dockerfile 的 ENTRYPOINT 中指定）以 root 用戶(hù)身份運(yùn)行。這樣一來(lái)，一旦攻擊者利用了一個(gè)漏洞并獲得了 shell 權(quán)限，他們就可以接管 Docker 守護(hù)程序所運(yùn)行的主機(jī)。

• 你的鏡像是基于一個(gè)過(guò)時(shí)的和 / 或不安全的基礎(chǔ)鏡像，其中包含（現(xiàn)在）眾所周知的安全漏洞。

• 你的鏡像包含了一些工具（如 curl、apt 等），一旦攻擊者獲得了某種訪問(wèn)權(quán)，就可以通過(guò)這些工具將惡意軟件加載到容器中。

下面的各個(gè)章節(jié)講解了能夠優(yōu)化你的鏡像安全性的各種方法。它們是按重要性 / 影響程度排序的，也就是說(shuō)排名靠前的方法更重要。

2避免泄露構(gòu)建密鑰

構(gòu)建密鑰是只在構(gòu)建 Docker 鏡像時(shí)需要的憑證（不是在運(yùn)行時(shí)）。例如，你可能想在你的鏡像中包含某個(gè)應(yīng)用程序的一個(gè)編譯版本，這個(gè)應(yīng)用的源代碼是閉源的，并且其 Git 存儲(chǔ)庫(kù)是有訪問(wèn)保護(hù)的。在構(gòu)建鏡像時(shí)，你需要克隆 Git 存儲(chǔ)庫(kù)（這需要構(gòu)建密鑰，例如該存儲(chǔ)庫(kù)的 SSH 訪問(wèn)密鑰），從源代碼構(gòu)建應(yīng)用程序，然后再刪除源代碼（和密鑰）。

“泄露“構(gòu)建密鑰是說(shuō)你不小心把這種密鑰烘焙到了你的鏡像的某個(gè)層中。這種情況很?chē)?yán)重，因?yàn)槔∧愕溺R像的所有人都可以檢索到這些機(jī)密。這個(gè)問(wèn)題源于這樣一個(gè)事實(shí)，即 Docker 鏡像是以純粹的加法方式逐層構(gòu)建的。你在一個(gè)層中刪除的文件只是被“標(biāo)記”為已刪除，但拉取你鏡像的人們?nèi)匀豢梢允褂酶呒?jí)工具訪問(wèn)它們。

可以使用以下兩種方法之一來(lái)避免泄露構(gòu)建密鑰。

多階段構(gòu)建

Docker 多階段構(gòu)建（官方文檔）有許多用例，例如加快你的鏡像構(gòu)建速度，或減少鏡像大小。本系列的其他文章會(huì)詳細(xì)介紹其他用例?？傊?，你也可以通過(guò)多階段構(gòu)建來(lái)避免泄露構(gòu)建密鑰，如下所示：

• 創(chuàng)建一個(gè)階段 #A，將憑證復(fù)制到其中，并使用它們來(lái)檢索其他工件（例如上述例子中的 Git 存儲(chǔ)庫(kù)）和執(zhí)行進(jìn)一步的步驟（例如編譯一個(gè)應(yīng)用程序）。階段 #A 的構(gòu)建確實(shí)包含了構(gòu)建的密鑰！

• 創(chuàng)建一個(gè) #B 階段，其中你只從 #A 階段復(fù)制非加密的工件，例如一個(gè)已編譯的應(yīng)用程序。

• 只發(fā)布 / 推送階段 #B 的鏡像

BuildKit 的密鑰

 背景知識(shí)

如果你使用 docker build 進(jìn)行構(gòu)建，可以實(shí)際執(zhí)行構(gòu)建的后端選項(xiàng)不止一個(gè)。其中較新和較快的后端是 BuildKit，你需要在 Linux 上設(shè)置環(huán)境變量 DOCKER_BUILDKIT=1 來(lái)顯式啟用它。注意，BuildKit 在 Windows/MacOS 的 Docker for Desktop 上是默認(rèn)啟用的。

正如這里的文檔所解釋的（閱讀它們以了解更多細(xì)節(jié)），BuildKit 構(gòu)建引擎支持 Dockerfile 中的額外語(yǔ)法。要使用構(gòu)建密鑰，請(qǐng)?jiān)谀愕?Dockerfile 中放入類(lèi)似下面這樣的內(nèi)容：

RUN --mount=type=secret,id=mysecret,dst=/foobar <command to run>

當(dāng) RUN 語(yǔ)句被執(zhí)行時(shí)，密鑰將對(duì)這個(gè)構(gòu)建容器可用，但不會(huì)將密鑰本身（這里是：/foobar 文件夾）放入構(gòu)建的鏡像中。你需要在運(yùn)行 docker build 命令時(shí)指定密鑰的源文件 / 文件夾（位于主機(jī)上）的路徑，例如：

docker build --secret id=mysecret,src=mysecret.txt -t sometag

不過(guò)有一點(diǎn)需要注意：你不能通過(guò) docker-compose up --build 來(lái)構(gòu)建需要密鑰的鏡像，因?yàn)?Docker-compose 還不支持用于構(gòu)建的 --secret 參數(shù)，見(jiàn) GitHub 問(wèn)題。如果你依賴(lài) docker-compose 的構(gòu)建，請(qǐng)使用方法 1（多階段構(gòu)建）。

 題外話：不要推送在開(kāi)發(fā)機(jī)上構(gòu)建的鏡像

你應(yīng)該一直在一個(gè)干凈的環(huán)境中構(gòu)建和推送鏡像（例如 CI/CD 管道），其中構(gòu)建代理會(huì)將你的存儲(chǔ)庫(kù)克隆到一個(gè)新目錄。

使用本地開(kāi)發(fā)機(jī)器進(jìn)行構(gòu)建的問(wèn)題是，你的本地 Git 存儲(chǔ)庫(kù)的“工作樹(shù)“可能是臟的。例如，它可能包含有開(kāi)發(fā)過(guò)程中需要的密鑰文件，例如對(duì)中轉(zhuǎn)甚至生產(chǎn)服務(wù)器的訪問(wèn)密鑰。如果沒(méi)有通過(guò).dockerignore 排除這些文件，那么 Dockerfile 中的“COPY . .“等語(yǔ)句可能會(huì)意外導(dǎo)致這些密鑰泄露到最終鏡像中。

3以非 root 用戶(hù)身份運(yùn)行

默認(rèn)情況下，當(dāng)有人通過(guò)“docker runyourImage:yourTag“運(yùn)行你的鏡像時(shí)，這個(gè)容器（以及你在 ENTRYPOINT/CMD 中的程序）會(huì)以 root 用戶(hù)身份運(yùn)行（在容器和主機(jī)上）。這給了一個(gè)使用某種漏洞在你的運(yùn)行容器中獲得 shell 權(quán)限的攻擊者以下權(quán)力：

• 對(duì)主機(jī)上所有顯式掛載到容器中的目錄的無(wú)限制寫(xiě)權(quán)限（因?yàn)槭?root）。

• 能夠在容器中做 Linux 根用戶(hù)可以做的一切事情。例如，攻擊者可以安裝他們需要的額外工具來(lái)加載更多的惡意軟件，比如說(shuō)通過(guò) apt-get install（非 root 用戶(hù)無(wú)法做到這一點(diǎn)）。

• 如果你的鏡像容器是用 docker run --privileged 啟動(dòng)的，攻擊者甚至可以接管整個(gè)主機(jī)。

為了避免這種情況，你應(yīng)該以非 root 用戶(hù)（你在 docker build 過(guò)程中創(chuàng)建的一些用戶(hù)）的身份運(yùn)行你的應(yīng)用程序。在你的 Dockerfile 中的某個(gè)地方（通常是在結(jié)尾處）放置以下語(yǔ)句

# Create a new user (including a home-directory, which is optional)
RUN useradd --create-home appuser
# Switch to this user
USER appuser

Dockerfile 中所有在 USER appuser 語(yǔ)句之后的命令（如 RUN、CMD 或 ENTRYPOINT）都將以這個(gè)用戶(hù)運(yùn)行。這里有一些需要注意的地方：

• 在切換到非 root 用戶(hù)之前，你通過(guò) COPY 復(fù)制到鏡像中的文件（或由某些 RUN 命令創(chuàng)建的文件）是由 root 用戶(hù)擁有的，因此以非 root 用戶(hù)身份運(yùn)行的應(yīng)用程序無(wú)法寫(xiě)入。為了解決這個(gè)問(wèn)題，請(qǐng)把創(chuàng)建和切換到非 root 用戶(hù)的代碼移到 Dockerfile 的開(kāi)頭。

• 如果這些文件是在 Dockerfile 的開(kāi)頭以根用戶(hù)身份創(chuàng)建的（存儲(chǔ)在 /root/ 下面，而不是 /home/appuser/ 下面），那么你的程序期望在用戶(hù)的主目錄中的某個(gè)地方（例如~/.cache）的文件，現(xiàn)在從應(yīng)用程序的視角來(lái)看可能突然消失了。

• 如果你的應(yīng)用程序監(jiān)聽(tīng)一個(gè) TCP/UDP 端口，就必須使用大于 1024 的端口。小于等于 1024 的端口只能以 root 用戶(hù)身份使用，或者以一些高級(jí) Linux 能力來(lái)使用，但你不應(yīng)該僅僅為了這個(gè)目的而給你的容器這些能力。

4使用最新的基礎(chǔ)鏡像構(gòu)建和更新系統(tǒng)包

如果你使用的基礎(chǔ)鏡像包含了某個(gè)真正的 Linux 發(fā)行版（如 Debian、Ubuntu 或 alpine 鏡像）的全部工具集，其中包括一個(gè)軟件包管理器，建議使用該軟件包管理器來(lái)安裝所有可用的軟件包更新。

背景知識(shí)

基礎(chǔ)鏡像是由某人維護(hù)的，他配置了 CI/CD 管道計(jì)劃來(lái)構(gòu)建基礎(chǔ)鏡像，并定期推送到 Docker Hub。你無(wú)法控制這個(gè)時(shí)間間隔，而且經(jīng)常發(fā)生的情況是，在該管道將更新的 Docker 鏡像推送到 Docker Hub 之前，Linux 發(fā)行版的包注冊(cè)表（例如通過(guò) apt）中已經(jīng)有了安全補(bǔ)丁。例如，即使基礎(chǔ)鏡像每周推送一次，也有可能在最近的鏡像發(fā)布幾小時(shí)或幾天后出現(xiàn)安全更新。

因此，最好總是運(yùn)行更新本地軟件包數(shù)據(jù)庫(kù)和安裝更新的包管理器命令，采用無(wú)人值守模式（不需要用戶(hù)確認(rèn)）。每個(gè) Linux 發(fā)行版的這個(gè)命令都不一樣。

例如，對(duì)于 Ubuntu、Debian 或衍生的發(fā)行版，使用 RUN apt-get update && apt-get -y upgrade

另一個(gè)重要的細(xì)節(jié)是，你需要告訴 Docker（或你使用的任何鏡像構(gòu)建工具）來(lái)刷新基礎(chǔ)鏡像。否則，如果你引用一個(gè)基礎(chǔ)鏡像，比如 python:3（而 Docker 在其本地鏡像緩存中已經(jīng)有了這樣一個(gè)鏡像），Docker 甚至不會(huì)檢查 Docker Hub 上是否存在更新的 python:3 版本。為了擺脫這種行為，你應(yīng)該使用這個(gè)命令：

docker build --pull <rest of the build command>

這可以確保 Docker 在構(gòu)建鏡像之前拉取你的 Dockerfile 中 FROM 語(yǔ)句中提到的鏡像的更新。

你還應(yīng)該注意 Docker 的層緩存機(jī)制，它會(huì)讓你的鏡像變得陳舊，因?yàn)?RUN <install apt/etc. updates>命令的層是緩存的，直到基礎(chǔ)鏡像維護(hù)者發(fā)布新版本的基礎(chǔ)鏡像才刷新。如果你發(fā)現(xiàn)基礎(chǔ)鏡像的發(fā)布頻率相當(dāng)?shù)停ū热缟儆谝恢芤淮危?，那么定期（比如每周一次）重建你的鏡像并禁用層緩存是個(gè)好主意。你可以運(yùn)行以下命令來(lái)做到這一點(diǎn)：

docker build --pull --no-cache <rest of the build command>

5定期更新第三方依賴(lài)

你編寫(xiě)的軟件是基于第三方的依賴(lài)，也就是由其他人制作的軟件。這包括了：

• 你的鏡像下面的基礎(chǔ) Docker 鏡像，或

• 你作為自己應(yīng)用程序的一部分使用的第三方軟件組件，例如通過(guò) pip/npm/gradle/apt/……安裝的組件。

如果你的鏡像中的這些依賴(lài)過(guò)時(shí)了，就會(huì)增加攻擊面，因?yàn)檫^(guò)時(shí)的依賴(lài)往往有可利用的安全漏洞。

你可以定期使用 SCA（軟件組件分析）工具來(lái)解決這個(gè)問(wèn)題，比如 Renovate Bot。這些工具（半）自動(dòng)將你聲明的第三方依賴(lài)更新為最新版本，例如在你的 Dockerfile、Python 的 requirements.txt、NPM 的 packages.json 等文件中聲明的列表。你需要設(shè)計(jì)你的 CI 管道，使 SCA 工具所做的更改自動(dòng)觸發(fā)你的鏡像的 re-build。

這種自動(dòng)觸發(fā)的鏡像重建對(duì)于處在只維護(hù)模式，但代碼仍將被客戶(hù)在生產(chǎn)環(huán)境中使用（客戶(hù)希望它是安全的）的項(xiàng)目特別有用。在維護(hù)期間，你不再開(kāi)發(fā)新的特性，也不會(huì)構(gòu)建新的鏡像，因?yàn)闆](méi)有新的提交（由你做出）來(lái)觸發(fā)新的構(gòu)建。然而，由 SCA 工具做出的提交確實(shí)會(huì)再次觸發(fā)鏡像構(gòu)建。

你可以在我的相關(guān)博文中找到更多關(guān)于 Renovate bot 的細(xì)節(jié)。

6對(duì)你的鏡像進(jìn)行漏洞掃描

即使你執(zhí)行了上述建議，比如說(shuō)你的鏡像總是使用最新的第三方依賴(lài)，它仍然可能是不安全的（例如一個(gè)依賴(lài)已經(jīng)被棄用的情況）。在這種情況下，“不安全“意味著一個(gè)（或多個(gè)）依賴(lài)有已知的安全漏洞（在一些 CVE 數(shù)據(jù)庫(kù)中注冊(cè)）。

出于這個(gè)原因，你可以給你的 Docker 鏡像提供某種工具來(lái)掃描所有包含的文件，以找到這種漏洞。這些工具有兩種形式：

• 你顯式調(diào)用的 CLI 工具（例如在 CI 管道中），比如說(shuō) Trivy（OSS，在 CI 管道中非常容易使用，見(jiàn) Trivy 文檔）、Clair（OSS，但設(shè)置和使用比 Trivy 更復(fù)雜），或 Snyk（通過(guò)“docker scan“集成到 Docker CLI 中，見(jiàn) cheat sheet，但只有有限的免費(fèi)計(jì)劃！)

• 集成到你推送鏡像的鏡像注冊(cè)中心的掃描器，如 Harbor（內(nèi)部使用 Clair 或 Trivy）。還有一些商業(yè)產(chǎn)品，如 Anchore。

因?yàn)檫@些掃描器是通用的，它們還試圖覆蓋一大堆包注冊(cè)表，所以可能不會(huì)特別為你在自己項(xiàng)目中使用的編程語(yǔ)言或包注冊(cè)表定制。有時(shí)，你應(yīng)該調(diào)查你的編程語(yǔ)言生態(tài)系統(tǒng)提供了哪些工具。例如，對(duì)于 Python 來(lái)說(shuō)就有一個(gè)專(zhuān)門(mén)針對(duì) Python 包的安全工具。

7掃描你的 Dockerfile 是否違反了最佳實(shí)踐

有時(shí)，問(wèn)題來(lái)自于你在 Dockerfile 中放置的語(yǔ)句，這些語(yǔ)句是不好的實(shí)踐（但你沒(méi)有意識(shí)到）。為此可以使用諸如 checkov、Conftest、trivy 或 hadolint 等工具，它們是 Dockerfile 的 linter。為了選擇正確的工具，你需要查看它的默認(rèn)規(guī)則 / 政策。例如，hadolint 比 checkov 或 conftest 提供的規(guī)則更多，因?yàn)樗菍?zhuān)門(mén)針對(duì) Dockerfiles 的。這些工具也是相互補(bǔ)充的，因此在你的 Dockerfiles 上運(yùn)行多個(gè)工具（如 hadolint 和 trivy）確實(shí)是有意義的。不過(guò)要做好準(zhǔn)備，因?yàn)槟阈枰S護(hù)“忽略文件“，在這個(gè)文件中的規(guī)則會(huì)被忽略——可能是由于誤報(bào)而有意忽略它們，或者是你準(zhǔn)備故意破壞規(guī)則。

8不要對(duì) Docker Hub 使用 Docker 內(nèi)容信任

為了驗(yàn)證你使用的基礎(chǔ)鏡像確實(shí)是由該鏡像背后的公司構(gòu)建和推送的，你可以使用 Docker 內(nèi)容信任（見(jiàn)官方文檔）特性。只需在運(yùn)行 docker build 或 docker pull 時(shí)將 DOCKER_CONTENT_TRUST 環(huán)境變量設(shè)為“1“即可啟用該特性。Docker 守護(hù)進(jìn)程將拒絕提取沒(méi)有經(jīng)過(guò)發(fā)布者簽名的鏡像。

不幸的是，大約一年前開(kāi)始社區(qū)就不再以這種方式簽名鏡像了。就連 Docker Inc. 也在 2020 年 12 月停止了簽名官方 Docker 鏡像，也沒(méi)有官方解釋。問(wèn)題更大的是如果你使用“docker pull docker:latest”這樣的命令，只會(huì)下載一個(gè)過(guò)時(shí)很久的鏡像。

你可以查看一下鏡像簽名的其他實(shí)現(xiàn)，比如說(shuō) cosign（不過(guò)我還沒(méi)試過(guò)）。

9掃描你自己的代碼是否有安全問(wèn)題

安全問(wèn)題通常來(lái)源于其他人的代碼，也就是流行的第三方依賴(lài)。因?yàn)樗鼈儜?yīng)用廣泛，所以在黑客那里是“有利可圖“的。然而，有時(shí)是你自己的代碼在作怪。例如，你可能不小心實(shí)現(xiàn)了 SQL 注入的可能性、堆棧溢出的錯(cuò)誤，等等。

為了找到這些問(wèn)題，你可以使用所謂的 SAST（靜態(tài)應(yīng)用安全測(cè)試）工具。一方面，有一些特定于編程語(yǔ)言的工具（你必須單獨(dú)研究），如 Python 的 bandit，或 Java 的 Checkstyle/Spotbugs。另一方面，還有一些支持多種編程語(yǔ)言和框架的工具套件（其中一些是非免費(fèi) / 商業(yè)的），如 SonarQube（對(duì)于它還有 SonarLint IDE 插件）。

在實(shí)踐中，安全掃描有兩種基本方法：

• 連續(xù)（自動(dòng)）掃描：你創(chuàng)建一個(gè) CI 作業(yè)，在每次推送時(shí)掃描你的代碼。這可以讓你的代碼安全性保持在一個(gè)較高的水平上，但你必須弄清楚如何忽略誤報(bào)（這是一項(xiàng)持續(xù)的維護(hù)工作）。如果你使用 GitLab，可能還會(huì)發(fā)現(xiàn) GitLab 的免費(fèi) SAST 功能很有趣。

• 不定期（手動(dòng)）掃描：團(tuán)隊(duì)中一些有安全意識(shí)的成員在本地運(yùn)行安全檢查，例如每月一次或每次發(fā)布前，并手動(dòng)查看結(jié)果。

10使用 docker-slim 來(lái)刪除不必要的文件

docker-slim 工具可以獲取大型 Docker 鏡像，臨時(shí)運(yùn)行它們，分析哪些文件在臨時(shí)容器中是被真正使用的，然后生成一個(gè)新的、單層的 Docker 鏡像——其中所有未使用的文件都會(huì)被刪除。這樣做有兩個(gè)好處：

• 鏡像被縮小

• 鏡像變得更加安全，因?yàn)椴恍枰墓ぞ弑粍h除了（例如 curl 或包管理器）。

請(qǐng)參考我之前文章中的 Docker slim 部分以了解更多細(xì)節(jié)。

11使用最小的基礎(chǔ)鏡像

一個(gè)鏡像中存儲(chǔ)的軟件（如 CLI 工具等）越多，攻擊面就越大。使用“最小“的鏡像是一個(gè)很好的實(shí)踐，它越小越好（無(wú)論如何這是一個(gè)很好的優(yōu)勢(shì)），并且應(yīng)該包含盡可能少的工具。最小的鏡像甚至超越了“優(yōu)化體積“的鏡像（如 alpine 或:-slim，如 python:3.8-slim）：前者沒(méi)有任何包管理器。這使攻擊者很難加載額外的工具。

最安全的最小基礎(chǔ)鏡像是 SCRATCH，它完全不包含任何東西。只有當(dāng)你在鏡像中放置自包含的二進(jìn)制文件時(shí)，才能用 FROM SCRATCH 啟動(dòng)你的 Dockerfile——這些二進(jìn)制文件烘焙進(jìn)了所有的依賴(lài)（包括 C-runtimes）。

如果 SCRATCH 不適合你，谷歌的無(wú)發(fā)行版（distroless）鏡像可以是一個(gè)很好的選擇，特別是當(dāng)你正在為常見(jiàn)的編程語(yǔ)言（如 Python 或 Node.js）構(gòu)建應(yīng)用程序，或者需要一個(gè)最小的 Debian 基礎(chǔ)鏡像時(shí)。

不幸的是，最小鏡像有幾個(gè)需要注意的地方：

• 無(wú)發(fā)行版的注意事項(xiàng)：

  • 不建議使用谷歌在 gcr.io 上發(fā)布的針對(duì)特定編程語(yǔ)言的鏡像，因?yàn)槟抢镏挥幸粋€(gè) latest 版本標(biāo)簽，以及 major 版本的標(biāo)簽（例如 python 的“3“，或 Node 的“12“）。你無(wú)法控制具體的語(yǔ)言運(yùn)行時(shí)版本（例如是否使用 Python 3.8.3 或 3.8.4 等），這破壞了你的鏡像構(gòu)建的可重用性。

  • 定制（和構(gòu)建你自己的）無(wú)發(fā)行版鏡像是相當(dāng)復(fù)雜的：你需要熟悉 Bazel 的構(gòu)建系統(tǒng)并自己構(gòu)建鏡像。

    • 注意：如果你唯一需要的定制是“以非 root 用戶(hù)身份運(yùn)行代碼”，那么每個(gè)無(wú)發(fā)行版基礎(chǔ)鏡像中都有一個(gè)默認(rèn)的非 root 用戶(hù)，詳見(jiàn)這里。

• 最小基礎(chǔ)鏡像的常規(guī)注意事項(xiàng)：

  • 使用最小基礎(chǔ)鏡像調(diào)試容器是很棘手的，因?yàn)橛杏玫墓ぞ撸ū热?/bin/sh）現(xiàn)在不見(jiàn)了。

    • 對(duì)于 Docker，你可以運(yùn)行第二個(gè)調(diào)試容器（它確實(shí)有一個(gè) shell 和調(diào)試工具，例如 alpine:latest），并使其共享你的最小容器的 PID 命名空間，例如通過(guò) docker run -it --rm --pid=container:

      --cap-add SYS_PTRACE alpine sh

    • 對(duì)于 Kubernetes，你可以使用短期容器，見(jiàn)這里的例子

12使用受信任的基礎(chǔ)鏡像

一個(gè)受信任的鏡像指的是經(jīng)過(guò)某人（要么是你自己的組織，要么是其他人）按照比如說(shuō)某種安全級(jí)別審核的鏡像。這對(duì)具有高安全要求和規(guī)定的受管制行業(yè)（銀行、航空航天等）來(lái)說(shuō)可能特別重要。

雖然你自己可以通過(guò)從頭開(kāi)始建立可信的鏡像來(lái)完成審計(jì)工作，但這是不可取的。因?yàn)槟悖ㄟ@個(gè)鏡像的構(gòu)建者）必須確保所有與審計(jì)有關(guān)的任務(wù)都已完成，并有正確的記錄（例如記錄鏡像中的包列表、執(zhí)行的 CVE 檢查及其結(jié)果等等）。這項(xiàng)任務(wù)非常繁重。相反，我們建議將這項(xiàng)工作外包出去，使用商業(yè)性的“可信注冊(cè)表“——它提供了一套選定的可信鏡像，如 RedHat 的通用基礎(chǔ)鏡像（UBI）。RedHat 的 UBI 現(xiàn)在也可以在 Docker Hub 上免費(fèi)獲取。

背景知識(shí)

在 Docker Hub 上托管的鏡像沒(méi)有經(jīng)過(guò)審計(jì)。它們是“按原樣“提供的。它們可能是不安全的（甚至包含惡意軟件），而且沒(méi)有人會(huì)通知你這一點(diǎn)。因此，使用 Docker Hub 中不安全的基礎(chǔ)鏡像也會(huì)讓你的鏡像變得不安全。

另外，你不應(yīng)該把審計(jì)和上面提到的 Docker 的內(nèi)容信任混為一談！內(nèi)容信任只確認(rèn)來(lái)源（鏡像上傳者）的身份，并不會(huì)確認(rèn)與鏡像安全性有關(guān)的任何事實(shí)。

13測(cè)試你的鏡像是否能在降低能力的情況下工作

Linux capabilities 是 Linux 內(nèi)核的一個(gè)特性，它允許你控制一個(gè)應(yīng)用程序可以使用哪些內(nèi)核特性，例如一個(gè)進(jìn)程是否可以發(fā)送信號(hào)（如 SIGKILL）、配置網(wǎng)絡(luò)接口、掛載磁盤(pán)，或調(diào)試進(jìn)程等。完整的列表見(jiàn)這里。一般來(lái)說(shuō)，你的應(yīng)用程序需要的功能越少越好。

啟動(dòng)你的鏡像容器的所有人都可以給予（或拿走）這些能力，例如通過(guò)調(diào)用“docker run --cap-drop=ALL “。默認(rèn)情況下 Docker 會(huì)放棄所有能力，除了這里定義的那些以外。你的應(yīng)用程序可能不需要所有這些功能。

作為一個(gè)最佳實(shí)踐，你可以嘗試啟動(dòng)你的鏡像容器，放棄所有能力（使用 --cap-drop=ALL），看看它是否仍然正常工作。如果不能，請(qǐng)搞清楚哪些功能是缺失的，并且你是否真的需要它們。然后請(qǐng)記錄你的鏡像需要哪些功能（以及為什么），這會(huì)給運(yùn)行你鏡像的用戶(hù)帶去更多信心。

14總結(jié)

提升你的鏡像安全性并非閑庭信步。你需要花時(shí)間來(lái)評(píng)估和實(shí)施每一種實(shí)踐。本文中的列表應(yīng)該可以節(jié)省你的時(shí)間，因?yàn)槭占团判蛑匾襟E的工作已經(jīng)為你做好了。

所幸，提升你的應(yīng)用程序的安全性是一個(gè)迭代過(guò)程。你可以從小處著手，每次實(shí)施一個(gè)步驟。不過(guò)你確實(shí)需要得到管理層的支持。這有時(shí)是很難辦的，特別是有時(shí)你的經(jīng)理會(huì)對(duì)建議有抵觸情緒，他們可能傾向于從過(guò)去的經(jīng)驗(yàn)來(lái)做推斷（“我們，或我們的客戶(hù)，以前從未被黑過(guò)，那么為什么這種問(wèn)題現(xiàn)在會(huì)發(fā)生在我們身上？我們需要的是特性！“）。你有幾個(gè)選擇：可以說(shuō)服你的經(jīng)理為安全性分配資源。例如，如果你有一個(gè)直接接觸客戶(hù)的渠道（你在為其構(gòu)建軟件），那么可以說(shuō)服他們，讓他們要求把安全性作為一個(gè)“特性“?；蛘咴谀愕男袠I(yè)中尋找安全漏洞的報(bào)告（例如一個(gè)直接的競(jìng)爭(zhēng)對(duì)手受到了影響），以證明黑客攻擊確實(shí)發(fā)生了，甚至你的行業(yè)也出了問(wèn)題，而且它們有嚴(yán)重的（財(cái)務(wù)）影響。

到此這篇關(guān)于優(yōu)化Docker鏡像安全性的12個(gè)技巧的文章就介紹到這了,更多相關(guān)優(yōu)化Docker鏡像安全性?xún)?nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

原文鏈接：

https://www.augmentedmind.de/2022/02/20/optimize-docker-image-security/

作者 | Marius    譯者 | 王強(qiáng)    策劃 | 閆園園