20250924 零信任下的容器安全供應鏈：從隔離到信任

https://www.digitimes.com.tw/Seminar/DevDaysAsia2025/agenda.html?from=lin_devdays

Transcript

1. 零信任下的容器安全供應鏈：從隔離到信任 Phil Huang <phil.huang@microsoft.com> Sr. Cloud Solution Architect | CNCF Ambassador 2025/09/24
3. Phil Huang 黃秉鈞 台灣微軟客戶成功事業群 Customer Success Unit, Microsoft Taiwan Sr. Cloud Solution Architect, Microsoft Customer Success Unit Pace Setter CNCF Ambassador Cloud Native Taiwan User Group Member Azure AI Foundry FLUX.1-Kontext-pro 感謝 George Liang @ Microsoft 貢獻此圖 潛水員 Phil 風格
4. 由 Black Forest Labs 開發的先進多模態 AI 模型 現已於 Azure AI Foundry 平台上可使用 https://learn.microsoft.com/en-us/azure/ai-foundry/foundry-models/concepts/models-sold-directly-by-azure?tabs=global-standard-aoai%2Cstandard-chat-completions%2Cglobal-standard&pivots=azure-direct- others#black-forest-labs-models-sold-directly-by-azure
5. 微軟安全容器供應鏈框架 Containers Secure Supply Chain (CSSC) Framework 符合 OCI 標準 容器映像檔 獲取 Acquire 安全地從外部來源 ，如 Microsoft Artifact Registry (MAR) 或第三方供 應商獲取容器映像 檔與相關產物 分類 Catalog 為內部開發團隊 提供一個經過審 核、管制的 “黃 金映像檔” 儲存 庫，作為唯一受 信任來源 建置 Build 導入 DevSecOps 產生符合規範、可 驗證且首信任的應 用程式容器映像檔 部署 Deploy 基於公司政策，確 保只有受信任且經 過驗證的映像檔能 夠被部署到正式的 運行環境中 運行 Run 持續監控運行環 境，保持其不受易 受攻擊和不合規的 套件影響，即時偵 測異常行為與回應 事件 真實性 和 完整性 確保任何從供應鏈中產生的交付物，如容器映 像檔，全程檢查其真實性與完整性 可視化 (o11y) 在供應鏈的每個階段產生認證或簽章；儲存並保 存這些資訊，以便後續稽核查詢和導入自動化 https://aka.ms/csscframework
6. 1. 獲取 (Acquire) 階段 Docker Hub GHCR NVIDIA NGC Catalog 受控隔離的 Azure 私人容器 映像倉庫 從外部容器目錄獲得基本容器映像檔，已 建立最小可用品質標準. • 驗證來源，如比對 SHA256 雜湊值和上游供應商可否信任 • 掃描漏洞和惡意軟體，如採用 Microsoft Defender for Container • 生成軟體物料清單 (SBOM)，如採用 microsoft/sbom-tool 最小可用 品質門檻 Catalog Stage 務必要注意獲取來源 Microsoft Artifact Registry (MAR) Red Hat Container Catalog 符合 OCI 標準規格 Azure Container Registry Microsoft Defender for Container
7. 建立最小可用品質標準 Microsoft Artifact Registry • 選擇方針：當有資安事件時， 找得到負責廠商或供應者修復 的容器映像檔來源 • 獲取映像檔時，使用 :latest 沒 有過錯，但請一並連同當時的 Tag 一起拉下來，主要留紀錄 • 使用映像檔時，強烈建議不要 使用 :latest，你會分辨不出來 現在用哪一個 • 映像檔所產生的 SHA 256 是你 唯一可以相信兩者是一樣映像 檔的基礎 主要是 sha256 要一樣 https://mcr.microsoft.com/
8. 了解當前安全態勢及嚴重性 (Severity) Microsoft Defender for Containers https://learn.microsoft.com/zh-tw/azure/defender-for-cloud/defender-for-containers-introduction • 基於 Azure Container Registry 整體性持 續性掃描，不區分單一映像檔 • 了解當前採用風險 • 相依性混淆 (Dependency Confusion) • URL 劫持 (Typo squatting) • 即時發現內嵌惡意軟體 • 已知 CVE 漏洞 • 資安左移 (Shift Left Security): 越前面發 現，後面修補成本會較低
9. 2. 分類 (Catalog) 階段 最小可用 品質門檻 為內部需求建立黃金樣板 “Golden Images” • 僅提供受信任且受支援的容器映像檔 • 持續掃描漏洞和惡意軟體 • 持續保持映像檔中的中繼資料最新狀態 Copa Trivy 可投入生 產門檻 受控隔離的 Azure 私人容器 映像倉庫 符合 OCI 標準規格 Microsoft Defender for Container Azure Container Registry
10. 當容器映像檔有漏洞的時候該怎麼辦?
11. 第一招：使用 Project Copacetic 直接修 • 由 Microsoft 支持且 2023/9 被 CNCF 收納為 Sandbox 專案等級 的開源計劃 • 主要提供“直接修補容器映像檔 漏洞” 的能力，大幅縮短緩解所 需的時間 • 採用 Buildkit，將所有必要的更新 套件打包層一個 Layer，並且疊加 在原始映像檔之上，並不會修改 任何現有的 Layer • 可搭配 GitHub Actions 或 ADO 等流程，讓流程自動化 • 並不是所有容器映像檔都適用 應對現代化容器映像檔需要直接且快速修復的迫切需求 https://blog.blackair.io/coldpatch-container-image-quick-and-efficient-container-image-patching-with-project-copacetic/
12. 第二招：直接重建容器映像檔 應對無法快速修復的容器映像檔 https://blog.blackair.io/coldpatch-container-image-re-build-image-using-patched-dockerfile/ # 匯入需要修補的映像檔 FROM mcr.microsoft.com/azure-cognitive-services/form- recognizer/layout-3.1:latest # 1. 修補 APT SSL 失效問題 COPY 80ssl-exceptions /etc/apt/apt.conf.d/80ssl-exceptions # 2. 若採用的是 non-root 的話，安裝套件需要切成 root USER root # 3. 僅安裝能修補的資安問題套件，其他不更新 RUN apt-get update && \ apt-get -s dist-upgrade | grep "^Inst" | grep -i securi | awk -F " " '{print $2}' | xargs apt-get install -y && \ apt-get clean && \ rm -rf /var/lib/apt/lists/* # 4. 將使用者切換回去 USER www-data • 技術上可用且無明顯副作用，但最好的做法還是上游要更新比較妥當 • 並不是每一個漏洞都可以被修補，有些漏洞太難被利用或根本用不到，會被棄修，大家都一樣 • 並不是所有容器映像檔都適用 會增加不少容量和 Layer
13. 3. 建置 (Build) 階段 可投入生 產門檻 以一致且安全的方式建置應用程 式容器映像檔. • 僅使用受信任的映像檔 • 編譯後需進行掃描漏洞和惡意軟體等動作 • 在建置期間或建置後修復已知漏洞 • 對映像檔或產生物件進行簽章 Github Action Azure DevOps CI/CD 容器映像 檔建置後 Microsoft Defender for Container
14. 採用 Notary 進行數位簽章 • 2025/03/31 後 Docker Content Trust 已被棄 用，Microsoft 將改用基於 Notary 專案提供 簽名和驗證的簽名方式 • Notary 專案主要要確保 2 個關鍵事情 1. 真實性 (Authenticity)：確認這個映像檔是誰 製作的，確保它來自可信的發布者 2. 完整性 (Integrity)：保證軟體從發佈到部署的 過程中沒有被任何人篡改過 • 可簽名和驗證的範圍 • SBOM 和掃描報告 • 遵循 OCI 標準的產出物 為容器映像檔提供數位“公證”系統 https://www.linkedin.com/posts/steven-r2_azurekeyvault-aks-docker-activity-7116544290553532416-p6AB/
15. 避免金鑰或憑證不小心包進去 • 推送保護 (Push Protection): 主要是在 Server 端執行的 pre-receive hook，當進 行 git commit 的時候，會對所有內容進 行大量比對已知的金鑰模式，若有發現有 金鑰在程式碼之內，則會拒絕 • 全面 Git Repo 掃描: 對整個完整 Git 歷史 中的所有文字檔進行掃描，而非單純只看 當前的紀錄 • 如果你真的很不巧推上去了，愛用 git- filter-repo 清理，而不是用 git push -- force GitHub Advanced Security (GHAS) / GitHub for Azure DevOps (GHAZDO)
16. 這是一個很正常的 Dockerfile
18. 4. 部署 (Deploy) 階段 容器映像 檔建置後 Deploy ACR Connected Registry 防止不合規的容器映像檔進入運行環境. • 持續掃描漏洞和惡意軟體 • 保持 Helm Chart 為最新的狀態 • 強制於 Kubernetes 上的 Admission Controller 執行部署 政策，如 Open Policy Agent (OPA) / Network Policies Helm Chart 部署 門檻 OPA Gatekeeper Ratify Azure Policy Microsoft Defender for Container
19. 僅允許 Notation 簽核的容器映像檔部署到 Kubernetes • 把簽署 (Notation) 拉進 k8s 准入點驗證， 確保只有可信的容器映像檔可以跑 • 部署流程 1. 簽署：使用已用 Notation 驗證的容器映 像檔 2. 信任：設定信任原則與 CA 憑證，以表 達誰是可信任簽署者和驗證等級 3. 定義 Kubernetes Admission Controller： 使用 OPA Gatekeeper 和 Ratify，匯餵 入簽署者的公鑰及憑證 4. 決定策略：套用 Ratify 的 ConstraintTemplate 與 Constraint，強 制 “未通過簽章驗證即拒絕部署” 以 OPA Gatekeeper + Ratify 守住供應鏈最後一道關卡 https://hackmd.io/@Feynman/SkP_qiWvn https://www.openpolicyagent.org/
20. 5. 運行 (Run) 階段 部署 門檻 Azure Kubernetes Service Azure Arc-enabled Kubernetes 監控並保持運行環境的一致性與安全性. • 持續掃描漏洞和惡意軟體，如 Microsoft Cloud for Containers - Runtime • 監控異常活動 • 保持運行節點的整潔，如使用 Image Cleaner Kubernetes Microsoft Defender for Container
21. 持續性進行生產環境弱掃和檢查 Microsoft Defender for Containers https://learn.microsoft.com/zh-tw/azure/defender-for-cloud/defender-for-containers- architecture?tabs=defender-for-container-arch-aks 功能 描述 機制 控制平面偵測 根據 Kubernetes 稽核日誌，偵測針 對 API Server 的可疑活動，例如異常 的權限提升或角色指派。 無代理程式分 析稽核日誌 工作負載偵測 監控容器化工作負載的執行階段行為， 偵測可疑的程序執行、網路連線或檔 案存取。 Defender 感 測器 (eBPF) 二進位檔案漂 移偵測 偵測在執行中容器內，由非原始映像 檔所包含的二進位檔案啟動的程序， 此為潛在入侵的強力指標。 Defender 感 測器 惡意軟體偵測 對 AKS 節點進行無代理程式掃描，以 偵測已知的惡意軟體。 無代理程式機 器掃描
22. 座落在地端的 Kubernetes 也可以受到保護 Azure Arc-enabled Kubernetes 支援 HTTP Proxy 連線模式
23. 總結 基於 CSSC 框架， 分階段處理供應鏈 議題，確保每個階 段的安全 1 供應鏈的不同階段需 要不同的工具和流程 ，但大部分都大同小 異 2 全程採用容器映像 檔簽章的方式，可 以強化真實性和完 整性 3 盡可能地做到資安左 移，儘早發現，儘早 修補 4
24. 加入社群，永續參與 Cloud Native Taiwan User Group （CNTUG）歡迎您的參與 目前有 8000 多位成員喔! • Kubernetes 和 CNCF 已經 滿 10週歲了！ • 我們在 DevDays Asia 2025 一樓有攤位和貼紙可以領取！
25. Thank you