優化Docker鏡像安全性的12個技巧總結

Posted on by

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

1前言

當你是剛開始使用 Docker 的新手時，你很可能會創建不安全的 Docker 鏡像，使攻擊者很容易借此接管容器，甚至可能接管整個主機，然後滲透到你公司的其他基礎設施中。

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

  • 啟動的應用程序（在你 Dockerfile 的 ENTRYPOINT 中指定）以 root 用戶身份運行。這樣一來，一旦攻擊者利用瞭一個漏洞並獲得瞭 shell 權限，他們就可以接管 Docker 守護程序所運行的主機。

  • 你的鏡像是基於一個過時的和 / 或不安全的基礎鏡像，其中包含（現在）眾所周知的安全漏洞。

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

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

2避免泄露構建密鑰

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

“泄露“構建密鑰是說你不小心把這種密鑰烘焙到瞭你的鏡像的某個層中。這種情況很嚴重，因為拉取你的鏡像的所有人都可以檢索到這些機密。這個問題源於這樣一個事實，即 Docker 鏡像是以純粹的加法方式逐層構建的。你在一個層中刪除的文件隻是被“標記”為已刪除，但拉取你鏡像的人們仍然可以使用高級工具訪問它們。

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

多階段構建

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

  • 創建一個階段 #A，將憑證復制到其中，並使用它們來檢索其他工件（例如上述例子中的 Git 存儲庫）和執行進一步的步驟（例如編譯一個應用程序）。階段 #A 的構建確實包含瞭構建的密鑰！

  • 創建一個 #B 階段，其中你隻從 #A 階段復制非加密的工件，例如一個已編譯的應用程序。

  • 隻發佈 / 推送階段 #B 的鏡像

BuildKit 的密鑰

 背景知識

如果你使用 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 . .“等語句可能會意外導致這些密鑰泄露到最終鏡像中。

3以非 root 用戶身份運行

默認情況下，當有人通過“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 能力來使用，但你不應該僅僅為瞭這個目的而給你的容器這些能力。

4使用最新的基礎鏡像構建和更新系統包

如果你使用的基礎鏡像包含瞭某個真正的 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 的細節。

6對你的鏡像進行漏洞掃描

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

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

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

  • 集成到你推送鏡像的鏡像註冊中心的掃描器，如 Harbor（內部使用 Clair 或 Trivy）。還有一些商業產品，如 Anchore。

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

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

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

8不要對 Docker Hub 使用 Docker 內容信任

為瞭驗證你使用的基礎鏡像確實是由該鏡像背後的公司構建和推送的，你可以使用 Docker 內容信任（見官方文檔）特性。隻需在運行 docker build 或 docker pull 時將 DOCKER_CONTENT_TRUST 環境變量設為“1“即可啟用該特性。Docker 守護進程將拒絕提取沒有經過發佈者簽名的鏡像。

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

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

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

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

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

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

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

  • 不定期（手動）掃描：團隊中一些有安全意識的成員在本地運行安全檢查，例如每月一次或每次發佈前，並手動查看結果。

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

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

  • 鏡像被縮小

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

請參考我之前文章中的 Docker slim 部分以瞭解更多細節。

11使用最小的基礎鏡像

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

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

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

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

  • 無發行版的註意事項：

    • 不建議使用谷歌在 gcr.io 上發佈的針對特定編程語言的鏡像，因為那裡隻有一個 latest 版本標簽，以及 major 版本的標簽（例如 python 的“3“，或 Node 的“12“）。你無法控制具體的語言運行時版本（例如是否使用 Python 3.8.3 或 3.8.4 等），這破壞瞭你的鏡像構建的可重用性。

    • 定制（和構建你自己的）無發行版鏡像是相當復雜的：你需要熟悉 Bazel 的構建系統並自己構建鏡像。

      • 註意：如果你唯一需要的定制是“以非 root 用戶身份運行代碼”，那麼每個無發行版基礎鏡像中都有一個默認的非 root 用戶，詳見這裡。

  • 最小基礎鏡像的常規註意事項：

    • 使用最小基礎鏡像調試容器是很棘手的，因為有用的工具（比如 /bin/sh）現在不見瞭。

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

        –cap-add SYS_PTRACE alpine sh

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

12使用受信任的基礎鏡像

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

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

背景知識

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

另外，你不應該把審計和上面提到的 Docker 的內容信任混為一談！內容信任隻確認來源（鏡像上傳者）的身份，並不會確認與鏡像安全性有關的任何事實。

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

Linux capabilities 是 Linux 內核的一個特性，它允許你控制一個應用程序可以使用哪些內核特性，例如一個進程是否可以發送信號（如 SIGKILL）、配置網絡接口、掛載磁盤，或調試進程等。完整的列表見這裡。一般來說，你的應用程序需要的功能越少越好。

啟動你的鏡像容器的所有人都可以給予（或拿走）這些能力，例如通過調用“docker run –cap-drop=ALL “。默認情況下 Docker 會放棄所有能力，除瞭這裡定義的那些以外。你的應用程序可能不需要所有這些功能。

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

14總結

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

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

到此這篇關於優化Docker鏡像安全性的12個技巧的文章就介紹到這瞭,更多相關優化Docker鏡像安全性內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet！

原文鏈接：

Docker optimization guide: the 12 best tips to optimize Docker image security

作者 | Marius    譯者 | 王強    策劃 | 閆園園

推薦閱讀：