溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要為大家展示了“優化Docker鏡像安全性的技巧有哪些”，內容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領大家一起研究并學習一下“優化Docker鏡像安全性的技巧有哪些”這篇文章吧。
當你是剛開始使用 Docker 的新手時，你很可能會創建不安全的 Docker 鏡像，使攻擊者很容易借此接管容器，甚至可能接管整個主機，然后滲透到你公司的其他基礎設施中。
可以被濫用來接管你的系統的攻擊向量有很多，例如：
啟動的應用程序（在你 Dockerfile 的 ENTRYPOINT 中指定）以 root 用戶身份運行。這樣一來，一旦攻擊者利用了一個漏洞并獲得了 shell 權限，他們就可以接管 Docker 守護程序所運行的主機。
你的鏡像是基于一個過時的和 / 或不安全的基礎鏡像，其中包含（現在）眾所周知的安全漏洞。
你的鏡像包含了一些工具（如 curl、apt 等），一旦攻擊者獲得了某種訪問權，就可以通過這些工具將惡意軟件加載到容器中。
下面的各個章節講解了能夠優化你的鏡像安全性的各種方法。它們是按重要性 / 影響程度排序的，也就是說排名靠前的方法更重要。
構建密鑰是只在構建 Docker 鏡像時需要的憑證（不是在運行時）。例如，你可能想在你的鏡像中包含某個應用程序的一個編譯版本，這個應用的源代碼是閉源的，并且其 Git 存儲庫是有訪問保護的。在構建鏡像時，你需要克隆 Git 存儲庫（這需要構建密鑰，例如該存儲庫的 SSH 訪問密鑰），從源代碼構建應用程序，然后再刪除源代碼（和密鑰）。
“泄露“構建密鑰是說你不小心把這種密鑰烘焙到了你的鏡像的某個層中。這種情況很嚴重，因為拉取你的鏡像的所有人都可以檢索到這些機密。這個問題源于這樣一個事實，即 Docker 鏡像是以純粹的加法方式逐層構建的。你在一個層中刪除的文件只是被“標記”為已刪除，但拉取你鏡像的人們仍然可以使用高級工具訪問它們。
可以使用以下兩種方法之一來避免泄露構建密鑰。
Docker 多階段構建（官方文檔）有許多用例，例如加快你的鏡像構建速度，或減少鏡像大小。本系列的其他文章會詳細介紹其他用例。總之，你也可以通過多階段構建來避免泄露構建密鑰，如下所示：
創建一個階段 #A，將憑證復制到其中，并使用它們來檢索其他工件（例如上述例子中的 Git 存儲庫）和執行進一步的步驟（例如編譯一個應用程序）。階段 #A 的構建確實包含了構建的密鑰！
創建一個 #B 階段，其中你只從 #A 階段復制非加密的工件，例如一個已編譯的應用程序。
只發布 / 推送階段 #B 的鏡像
背景知識
如果你使用 docker build 進行構建，可以實際執行構建的后端選項不止一個。其中較新和較快的后端是 BuildKit，你需要在 Linux 上設置環境變量 DOCKER_BUILDKIT=1 來顯式啟用它。注意，BuildKit 在 Windows/MacOS 的 Docker for Desktop 上是默認啟用的。
正如這里的文檔所解釋的（閱讀它們以了解更多細節），BuildKit 構建引擎支持 Dockerfile 中的額外語法。要使用構建密鑰，請在你的 Dockerfile 中放入類似下面這樣的內容：
RUN --mount=type=secret,id=mysecret,dst=/foobar <command to run>
當 RUN 語句被執行時，密鑰將對這個構建容器可用，但不會將密鑰本身（這里是：/foobar 文件夾）放入構建的鏡像中。你需要在運行 docker build 命令時指定密鑰的源文件 / 文件夾（位于主機上）的路徑，例如：
docker build --secret id=mysecret,src=mysecret.txt -t sometag
不過有一點需要注意：你不能通過 docker-compose up --build 來構建需要密鑰的鏡像，因為 Docker-compose 還不支持用于構建的 --secret 參數，見 GitHub 問題。如果你依賴 docker-compose 的構建，請使用方法 1（多階段構建）。
你應該一直在一個干凈的環境中構建和推送鏡像（例如 CI/CD 管道），其中構建代理會將你的存儲庫克隆到一個新目錄。
使用本地開發機器進行構建的問題是，你的本地 Git 存儲庫的“工作樹“可能是臟的。例如，它可能包含有開發過程中需要的密鑰文件，例如對中轉甚至生產服務器的訪問密鑰。如果沒有通過.dockerignore 排除這些文件，那么 Dockerfile 中的“COPY . .“等語句可能會意外導致這些密鑰泄露到最終鏡像中。
默認情況下，當有人通過“docker runyourImage:yourTag“運行你的鏡像時，這個容器（以及你在 ENTRYPOINT/CMD 中的程序）會以 root 用戶身份運行（在容器和主機上）。這給了一個使用某種漏洞在你的運行容器中獲得 shell 權限的攻擊者以下權力：
對主機上所有顯式掛載到容器中的目錄的無限制寫權限（因為是 root）。
能夠在容器中做 Linux 根用戶可以做的一切事情。例如，攻擊者可以安裝他們需要的額外工具來加載更多的惡意軟件，比如說通過 apt-get install（非 root 用戶無法做到這一點）。
如果你的鏡像容器是用 docker run --privileged 啟動的，攻擊者甚至可以接管整個主機。
為了避免這種情況，你應該以非 root 用戶（你在 docker build 過程中創建的一些用戶）的身份運行你的應用程序。在你的 Dockerfile 中的某個地方（通常是在結尾處）放置以下語句
# 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）都將以這個用戶運行。這里有一些需要注意的地方：
在切換到非 root 用戶之前，你通過 COPY 復制到鏡像中的文件（或由某些 RUN 命令創建的文件）是由 root 用戶擁有的，因此以非 root 用戶身份運行的應用程序無法寫入。為了解決這個問題，請把創建和切換到非 root 用戶的代碼移到 Dockerfile 的開頭。
如果這些文件是在 Dockerfile 的開頭以根用戶身份創建的（存儲在 /root/ 下面，而不是 /home/appuser/ 下面），那么你的程序期望在用戶的主目錄中的某個地方（例如~/.cache）的文件，現在從應用程序的視角來看可能突然消失了。
如果你的應用程序監聽一個 TCP/UDP 端口，就必須使用大于 1024 的端口。小于等于 1024 的端口只能以 root 用戶身份使用，或者以一些高級 Linux 能力來使用，但你不應該僅僅為了這個目的而給你的容器這些能力。
如果你使用的基礎鏡像包含了某個真正的 Linux 發行版（如 Debian、Ubuntu 或 alpine 鏡像）的全部工具集，其中包括一個軟件包管理器，建議使用該軟件包管理器來安裝所有可用的軟件包更新。
基礎鏡像是由某人維護的，他配置了 CI/CD 管道計劃來構建基礎鏡像，并定期推送到 Docker Hub。你無法控制這個時間間隔，而且經常發生的情況是，在該管道將更新的 Docker 鏡像推送到 Docker Hub 之前，Linux 發行版的包注冊表（例如通過 apt）中已經有了安全補丁。例如，即使基礎鏡像每周推送一次，也有可能在最近的鏡像發布幾小時或幾天后出現安全更新。
因此，最好總是運行更新本地軟件包數據庫和安裝更新的包管理器命令，采用無人值守模式（不需要用戶確認）。每個 Linux 發行版的這個命令都不一樣。
例如，對于 Ubuntu、Debian 或衍生的發行版，使用 RUN apt-get update && apt-get -y upgrade
另一個重要的細節是，你需要告訴 Docker（或你使用的任何鏡像構建工具）來刷新基礎鏡像。否則，如果你引用一個基礎鏡像，比如 python:3（而 Docker 在其本地鏡像緩存中已經有了這樣一個鏡像），Docker 甚至不會檢查 Docker Hub 上是否存在更新的 python:3 版本。為了擺脫這種行為，你應該使用這個命令：
docker build --pull <rest of the build command>
這可以確保 Docker 在構建鏡像之前拉取你的 Dockerfile 中 FROM 語句中提到的鏡像的更新。
你還應該注意 Docker 的層緩存機制，它會讓你的鏡像變得陳舊，因為 RUN <install apt/etc. updates>命令的層是緩存的，直到基礎鏡像維護者發布新版本的基礎鏡像才刷新。如果你發現基礎鏡像的發布頻率相當低（比如少于一周一次），那么定期（比如每周一次）重建你的鏡像并禁用層緩存是個好主意。你可以運行以下命令來做到這一點：
docker build --pull --no-cache <rest of the build command>
5定期更新第三方依賴
你編寫的軟件是基于第三方的依賴，也就是由其他人制作的軟件。這包括了：
你的鏡像下面的基礎 Docker 鏡像，或
你作為自己應用程序的一部分使用的第三方軟件組件，例如通過 pip/npm/gradle/apt/……安裝的組件。
如果你的鏡像中的這些依賴過時了，就會增加攻擊面，因為過時的依賴往往有可利用的安全漏洞。
你可以定期使用 SCA（軟件組件分析）工具來解決這個問題，比如 Renovate Bot。這些工具（半）自動將你聲明的第三方依賴更新為最新版本，例如在你的 Dockerfile、Python 的 requirements.txt、NPM 的 packages.json 等文件中聲明的列表。你需要設計你的 CI 管道，使 SCA 工具所做的更改自動觸發你的鏡像的 re-build。
這種自動觸發的鏡像重建對于處在只維護模式，但代碼仍將被客戶在生產環境中使用（客戶希望它是安全的）的項目特別有用。在維護期間，你不再開發新的特性，也不會構建新的鏡像，因為沒有新的提交（由你做出）來觸發新的構建。然而，由 SCA 工具做出的提交確實會再次觸發鏡像構建。
你可以在我的相關博文中找到更多關于 Renovate bot 的細節。
即使你執行了上述建議，比如說你的鏡像總是使用最新的第三方依賴，它仍然可能是不安全的（例如一個依賴已經被棄用的情況）。在這種情況下，“不安全“意味著一個（或多個）依賴有已知的安全漏洞（在一些 CVE 數據庫中注冊）。
出于這個原因，你可以給你的 Docker 鏡像提供某種工具來掃描所有包含的文件，以找到這種漏洞。這些工具有兩種形式：
你顯式調用的 CLI 工具（例如在 CI 管道中），比如說 Trivy（OSS，在 CI 管道中非常容易使用，見 Trivy 文檔）、Clair（OSS，但設置和使用比 Trivy 更復雜），或 Snyk（通過“docker scan“集成到 Docker CLI 中，見 cheat sheet，但只有有限的免費計劃！)
集成到你推送鏡像的鏡像注冊中心的掃描器，如 Harbor（內部使用 Clair 或 Trivy）。還有一些商業產品，如 Anchore。
因為這些掃描器是通用的，它們還試圖覆蓋一大堆包注冊表，所以可能不會特別為你在自己項目中使用的編程語言或包注冊表定制。有時，你應該調查你的編程語言生態系統提供了哪些工具。例如，對于 Python 來說就有一個專門針對 Python 包的安全工具。
有時，問題來自于你在 Dockerfile 中放置的語句，這些語句是不好的實踐（但你沒有意識到）。為此可以使用諸如 checkov、Conftest、trivy 或 hadolint 等工具，它們是 Dockerfile 的 linter。為了選擇正確的工具，你需要查看它的默認規則 / 政策。例如，hadolint 比 checkov 或 conftest 提供的規則更多，因為它是專門針對 Dockerfiles 的。這些工具也是相互補充的，因此在你的 Dockerfiles 上運行多個工具（如 hadolint 和 trivy）確實是有意義的。不過要做好準備，因為你需要維護“忽略文件“，在這個文件中的規則會被忽略——可能是由于誤報而有意忽略它們，或者是你準備故意破壞規則。
為了驗證你使用的基礎鏡像確實是由該鏡像背后的公司構建和推送的，你可以使用 Docker 內容信任（見官方文檔）特性。只需在運行 docker build 或 docker pull 時將 DOCKER_CONTENT_TRUST 環境變量設為“1“即可啟用該特性。Docker 守護進程將拒絕提取沒有經過發布者簽名的鏡像。
不幸的是，大約一年前開始社區就不再以這種方式簽名鏡像了。就連 Docker Inc. 也在 2020 年 12 月停止了簽名官方 Docker 鏡像，也沒有官方解釋。問題更大的是如果你使用“docker pull docker:latest”這樣的命令，只會下載一個過時很久的鏡像。
你可以查看一下鏡像簽名的其他實現，比如說 cosign（不過我還沒試過）。
安全問題通常來源于其他人的代碼，也就是流行的第三方依賴。因為它們應用廣泛，所以在黑客那里是“有利可圖“的。然而，有時是你自己的代碼在作怪。例如，你可能不小心實現了 SQL 注入的可能性、堆棧溢出的錯誤，等等。
為了找到這些問題，你可以使用所謂的 SAST（靜態應用安全測試）工具。一方面，有一些特定于編程語言的工具（你必須單獨研究），如 Python 的 bandit，或 Java 的 Checkstyle/Spotbugs。另一方面，還有一些支持多種編程語言和框架的工具套件（其中一些是非免費 / 商業的），如 SonarQube（對于它還有 SonarLint IDE 插件）。
在實踐中，安全掃描有兩種基本方法：
連續（自動）掃描：你創建一個 CI 作業，在每次推送時掃描你的代碼。這可以讓你的代碼安全性保持在一個較高的水平上，但你必須弄清楚如何忽略誤報（這是一項持續的維護工作）。如果你使用 GitLab，可能還會發現 GitLab 的免費 SAST 功能很有趣。
不定期（手動）掃描：團隊中一些有安全意識的成員在本地運行安全檢查，例如每月一次或每次發布前，并手動查看結果。
docker-slim 工具可以獲取大型 Docker 鏡像，臨時運行它們，分析哪些文件在臨時容器中是被真正使用的，然后生成一個新的、單層的 Docker 鏡像——其中所有未使用的文件都會被刪除。這樣做有兩個好處：
鏡像被縮小
鏡像變得更加安全，因為不需要的工具被刪除了（例如 curl 或包管理器）。
請參考我之前文章中的 Docker slim 部分以了解更多細節。
一個鏡像中存儲的軟件（如 CLI 工具等）越多，攻擊面就越大。使用“最小“的鏡像是一個很好的實踐，它越小越好（無論如何這是一個很好的優勢），并且應該包含盡可能少的工具。最小的鏡像甚至超越了“優化體積“的鏡像（如 alpine 或:-slim，如 python:3.8-slim）：前者沒有任何包管理器。這使攻擊者很難加載額外的工具。
最安全的最小基礎鏡像是 SCRATCH，它完全不包含任何東西。只有當你在鏡像中放置自包含的二進制文件時，才能用 FROM SCRATCH 啟動你的 Dockerfile——這些二進制文件烘焙進了所有的依賴（包括 C-runtimes）。
如果 SCRATCH 不適合你，谷歌的無發行版（distroless）鏡像可以是一個很好的選擇，特別是當你正在為常見的編程語言（如 Python 或 Node.js）構建應用程序，或者需要一個最小的 Debian 基礎鏡像時。
不幸的是，最小鏡像有幾個需要注意的地方：
無發行版的注意事項：
注意：如果你唯一需要的定制是“以非 root 用戶身份運行代碼”，那么每個無發行版基礎鏡像中都有一個默認的非 root 用戶，詳見這里。
不建議使用谷歌在 gcr.io 上發布的針對特定編程語言的鏡像，因為那里只有一個 latest 版本標簽，以及 major 版本的標簽（例如 python 的“3“，或 Node 的“12“）。你無法控制具體的語言運行時版本（例如是否使用 Python 3.8.3 或 3.8.4 等），這破壞了你的鏡像構建的可重用性。
定制（和構建你自己的）無發行版鏡像是相當復雜的：你需要熟悉 Bazel 的構建系統并自己構建鏡像。
最小基礎鏡像的常規注意事項：
對于 Docker，你可以運行第二個調試容器（它確實有一個 shell 和調試工具，例如 alpine:latest），并使其共享你的最小容器的 PID 命名空間，例如通過 docker run -it --rm --pid=container:
--cap-add SYS_PTRACE alpine sh
對于 Kubernetes，你可以使用短期容器，見這里的例子
使用最小基礎鏡像調試容器是很棘手的，因為有用的工具（比如 /bin/sh）現在不見了。
一個受信任的鏡像指的是經過某人（要么是你自己的組織，要么是其他人）按照比如說某種安全級別審核的鏡像。這對具有高安全要求和規定的受管制行業（銀行、航空航天等）來說可能特別重要。
雖然你自己可以通過從頭開始建立可信的鏡像來完成審計工作，但這是不可取的。因為你（這個鏡像的構建者）必須確保所有與審計有關的任務都已完成，并有正確的記錄（例如記錄鏡像中的包列表、執行的 CVE 檢查及其結果等等）。這項任務非常繁重。相反，我們建議將這項工作外包出去，使用商業性的“可信注冊表“——它提供了一套選定的可信鏡像，如 RedHat 的通用基礎鏡像（UBI）。RedHat 的 UBI 現在也可以在 Docker Hub 上免費獲取。
在 Docker Hub 上托管的鏡像沒有經過審計。它們是“按原樣“提供的。它們可能是不安全的（甚至包含惡意軟件），而且沒有人會通知你這一點。因此，使用 Docker Hub 中不安全的基礎鏡像也會讓你的鏡像變得不安全。
另外，你不應該把審計和上面提到的 Docker 的內容信任混為一談！內容信任只確認來源（鏡像上傳者）的身份，并不會確認與鏡像安全性有關的任何事實。
Linux capabilities 是 Linux 內核的一個特性，它允許你控制一個應用程序可以使用哪些內核特性，例如一個進程是否可以發送信號（如 SIGKILL）、配置網絡接口、掛載磁盤，或調試進程等。完整的列表見這里。一般來說，你的應用程序需要的功能越少越好。
啟動你的鏡像容器的所有人都可以給予（或拿走）這些能力，例如通過調用“docker run --cap-drop=ALL “。默認情況下 Docker 會放棄所有能力，除了這里定義的那些以外。你的應用程序可能不需要所有這些功能。
作為一個最佳實踐，你可以嘗試啟動你的鏡像容器，放棄所有能力（使用 --cap-drop=ALL），看看它是否仍然正常工作。如果不能，請搞清楚哪些功能是缺失的，并且你是否真的需要它們。然后請記錄你的鏡像需要哪些功能（以及為什么），這會給運行你鏡像的用戶帶去更多信心。
以上是“優化Docker鏡像安全性的技巧有哪些”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
