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

1前言

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

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

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

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

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

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

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

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

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

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

多階段構(gòu)建

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

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

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

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

BuildKit 的密鑰

 背景知識

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

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

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

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

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

不過有一點需要注意：你不能通過 docker-compose up --build 來構(gòu)建需要密鑰的鏡像，因為 Docker-compose 還不支持用于構(gòu)建的 --secret 參數(shù)，見 GitHub 問題。如果你依賴 docker-compose 的構(gòu)建，請使用方法 1（多階段構(gòu)建）。

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

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

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

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

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

• 對主機(jī)上所有顯式掛載到容器中的目錄的無限制寫權(quán)限（因為是 root）。

• 能夠在容器中做 Linux 根用戶可以做的一切事情。例如，攻擊者可以安裝他們需要的額外工具來加載更多的惡意軟件，比如說通過 apt-get install（非 root 用戶無法做到這一點）。

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

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

# 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 語句之后的命令（如 RUN、CMD 或 ENTRYPOINT）都將以這個用戶運(yùn)行。這里有一些需要注意的地方：

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

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

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

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

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

背景知識

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

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

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

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

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

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

你還應(yīng)該注意 Docker 的層緩存機(jī)制，它會讓你的鏡像變得陳舊，因為 RUN <install apt/etc. updates>命令的層是緩存的，直到基礎(chǔ)鏡像維護(hù)者發(fā)布新版本的基礎(chǔ)鏡像才刷新。如果你發(fā)現(xiàn)基礎(chǔ)鏡像的發(fā)布頻率相當(dāng)?shù)停ū热缟儆谝恢芤淮危敲炊ㄆ冢ū热缑恐芤淮危┲亟愕溺R像并禁用層緩存是個好主意。你可以運(yùn)行以下命令來做到這一點：

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

5定期更新第三方依賴

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

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

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

如果你的鏡像中的這些依賴過時了，就會增加攻擊面，因為過時的依賴往往有可利用的安全漏洞。

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

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

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

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

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

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

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

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

因為這些掃描器是通用的，它們還試圖覆蓋一大堆包注冊表，所以可能不會特別為你在自己項目中使用的編程語言或包注冊表定制。有時，你應(yīng)該調(diào)查你的編程語言生態(tài)系統(tǒng)提供了哪些工具。例如，對于 Python 來說就有一個專門針對 Python 包的安全工具。

7掃描你的 Dockerfile 是否違反了最佳實踐

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

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

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

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

你可以查看一下鏡像簽名的其他實現(xiàn)，比如說 cosign（不過我還沒試過）。

9掃描你自己的代碼是否有安全問題

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

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

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

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

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

10使用 docker-slim 來刪除不必要的文件

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

• 鏡像被縮小

• 鏡像變得更加安全，因為不需要的工具被刪除了（例如 curl 或包管理器）。

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

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

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

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

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

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

• 無發(fā)行版的注意事項：

  • 不建議使用谷歌在 gcr.io 上發(fā)布的針對特定編程語言的鏡像，因為那里只有一個 latest 版本標(biāo)簽，以及 major 版本的標(biāo)簽（例如 python 的“3“，或 Node 的“12“）。你無法控制具體的語言運(yùn)行時版本（例如是否使用 Python 3.8.3 或 3.8.4 等），這破壞了你的鏡像構(gòu)建的可重用性。

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

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

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

  • 使用最小基礎(chǔ)鏡像調(diào)試容器是很棘手的，因為有用的工具（比如 /bin/sh）現(xiàn)在不見了。

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

      --cap-add SYS_PTRACE alpine sh

    • 對于 Kubernetes，你可以使用短期容器，見這里的例子

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

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

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

背景知識

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

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

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

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

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

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

14總結(jié)

提升你的鏡像安全性并非閑庭信步。你需要花時間來評估和實施每一種實踐。本文中的列表應(yīng)該可以節(jié)省你的時間，因為收集和排序重要步驟的工作已經(jīng)為你做好了。

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

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

原文鏈接：

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

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

最新評論