Docker Content Trust 正式退役：DCT 與 Notary v1 停服時程及遷移指南
Docker Blog · 2026-06-16
Docker 於 2026 年 6 月 16 日宣布，Docker Content Trust（DCT）及其底層基礎設施 Notary v1 服務（notary.docker.io）將於 2026 年 12 月 8 日全面停服。此決定涵蓋所有 docker trust 子指令、環境變數 DOCKER_CONTENT_TRUST=1 所觸發的自動驗證機制，以及依賴 TUF（The Update Framework）委派模型的映像簽署基礎設施。受影響的團隊須在停服前完成遷移，否則簽署與驗證流程將中斷。
背景
DCT 最初隨 Docker Engine 1.8（2015 年）推出，基於 Notary v1 提供以 TUF 為基礎的映像簽署與信任根（root of trust）。Notary v1 的核心程式碼已超過十年未進行重大維護，技術債持續累積。與此同時，OCI 規範（Open Container Initiative）的普及帶動了新一代簽署工具的崛起，使得以私有服務為中心的 DCT 架構逐漸與生態系脫節。
Docker 的遙測資料顯示，使用 DCT 的映像拉取量不足 Docker Hub 總拉取量的 0.05%，採用率極低。Azure Container Registry 與 Harbor 等主流 Registry 早已棄用 Notary v1 支援。此外，CNCF 旗下的 Notary Project 於數年前便轉向開發 Notation（基於 OCI reference artifacts 的下一代工具），進一步確立了 Notary v1 的生命週期終點。
停服時程
Docker 規劃了一系列 brownout 停機測試，讓用戶在完全停服前驗證自身系統是否受影響。所有停機視窗均落在太平洋時間上午 8 時，持續 4 小時。
| 日期 | 事件 |
|---|---|
| 2026-07-14 | 寫入 brownout（4 小時） |
| 2026-07-15 | 寫入 brownout（4 小時） |
| 2026-08-10 | 讀取 brownout（4 小時） |
| 2026-08-12 | 讀取 brownout（4 小時） |
| 2026-12-08 | 全面停服 |
未曾設定 DOCKER_CONTENT_TRUST=1、也未使用 docker trust 指令的用戶不受影響；一般的 docker pull 與 docker push 操作完全不涉及此變更。
核心改動：受影響的使用情境
以下情境需要主動評估並遷移：
- Shell 設定檔（
.bashrc、.zshrc）或 CI/CD 環境變數中含有DOCKER_CONTENT_TRUST=1 - CI pipeline 中呼叫
docker trust sign、docker trust inspect、docker trust revoke - Kubernetes 准入控制器（Admission Controller）依賴 DCT 簽章做映像驗證
- 在 Docker Hub 上以 DCT 發佈映像的映像發佈者
第一步最為簡單：在受影響的 shell 環境與 CI 腳本中移除或取消設定該環境變數。
# 在目前的 shell 工作階段中移除
unset DOCKER_CONTENT_TRUST
# 或明確停用
export DOCKER_CONTENT_TRUST=0
影響範圍：遷移至現代簽署工具
Docker 官方建議遷移至兩種主流方案之一。Sigstore/Cosign 採用以 OIDC 身份為基礎的短期憑證（keyless signing），簽章以 OCI artifact 形式儲存於 Registry，無需管理長期私鑰；Notation 則採用傳統 PKI 模型，以 X.509 憑證簽署，同樣將簽章儲存為 OCI reference artifact。
Cosign 的核心工作流程如下：
# 以 keyless 模式簽署（透過 OIDC 身份認證）
cosign sign $IMAGE
# 驗證簽章（指定發行者與身份）
cosign verify $IMAGE \
--certificate-identity=$IDENTITY \
--certificate-oidc-issuer=$OIDC_ISSUER
在 Kubernetes 叢集中強制驗證簽章，可搭配 Kyverno（配合 Cosign）或 Ratify + OPA Gatekeeper（配合 Notation）作為准入控制層。若不需要加密簽署，改用映像摘要（digest）固定版本（image@sha256:...）可保障內容完整性，確保拉取的映像不因標籤（tag）可變性而遭到替換，但無法驗證發佈者身份。Docker 同時推出 Docker Hardened Images（DHI）社群版，提供含 SLSA Build Level 3 出處記錄、已簽署 SBOM 及低 CVE 數量的最小化映像，可作為遷移期間的受信任基礎映像選擇。
原始來源：Docker Blog — Docker Content Trust Retirement and Migration Guidance、Sigstore/Cosign GitHub
從資料落地到數位主權：雲原生平台的架構模式
CNCF Blog · 2026-06-16
CNCF 於 2026 年 6 月 16 日發布一篇深度架構指南，系統性地梳理雲原生平台在歐盟 Data Act、NIS-2 指令、DORA 及英國 Data Use and Access Act 2025 等多重法規框架下的設計挑戰。文章從「資料落地（data residency）」與「數位主權（digital sovereignty）」的概念差異出發，提出以 Kubernetes 租戶叢集作為主權隔離基本單元（sovereignty primitive）的具體架構模式。
原本的問題
「資料落地」通常僅要求靜態資料儲存於特定地理位置，而「數位主權」的要求遠比落地更嚴格——它要求控制平面本身、加密金鑰與作業自主性均須落在可依法主張的司法管轄範圍內。以多租戶 SaaS 平台為例，若 API server 與 etcd 共用於多個租戶或跨越多個法律管轄，光靠節點選擇器（node selector）將資料限制在特定節點，並無法滿足 NIS-2 對「可稽核隔離」的要求。
作者將主權需求分解為四個屬性：
- 司法管轄封閉性：所有可讀取租戶資料的元件（含控制平面）均在組織可具名並合法捍衛的管轄範圍內運作
- 作業自主性：團隊可在不依賴供應商的情況下重建、遷移與稽核工作負載
- 加密與存取控制：金鑰、etcd 內容與憑證均不可在選定管轄區外被存取
- 可攜性：工作負載可跨基礎設施遷移，無需重寫
採用的方法
核心架構模式是以租戶叢集作為主權隔離基本單元，即為每個隔離邊界建立獨立的 Kubernetes 控制平面，以 Pod 形式運行於共享底層基礎設施之上。每個租戶叢集擁有獨立的 API server 與後端儲存（可為嵌入式 etcd、外部 etcd 或 SQL 資料庫）。
文章以 vCluster 作為參考實作，示範如何在現有 Kubernetes 叢集之上，以 Pod 形式佈建租戶叢集。租戶叢集的狀態可存放於受操作者控制的加密磁碟區，實現司法管轄特定的後端儲存。如需更強的隔離，可搭配 user-namespace runtime、gVisor 或 Kata Containers。
推薦的 2026 年主權平台架構元件組合如下：
- 少量位於主權基礎設施上的底層 Kubernetes 叢集
- 每個管轄區擁有獨立控制平面的租戶叢集
- 以 Argo CD 或 Flux 管理 GitOps 宣告式部署
- 在叢集層與租戶層均部署 Kyverno 或 OPA Gatekeeper 執行政策
- 僅匯出至管轄區本地的稽核日誌接收端（audit log sinks），確保日誌不跨越法規邊界
- 以標準 Kubernetes API 確保工作負載可攜性
以多管轄區 SaaS 場景為例，歐盟與英國客戶各自擁有獨立的租戶叢集，並透過節點選擇器強制落地、各自的後端儲存與本地稽核日誌接收端，搭配管轄區特定的政策套件（policy bundle）確保映像出處要求。SPIFFE/SPIRE 負責工作負載身份，Cilium 處理網路層的管轄區隔離，而 Metal3 與 Tinkerbell 則用於需要裸機佈建的場景。
實際效果
此模式的核心價值在於將法規隔離需求從應用程式層下移至平台層，使開發者無需在每個服務中自行處理資料主權邏輯。然而，文章同時明確指出此模式的限制：它不能推翻底層叢集操作者所在法律管轄的效力；也不能取代完整的安全技術堆疊（政策引擎、SBOM pipeline、稽核日誌）；同時每個控制平面都帶來獨立的監控、升級與備份負擔。
文章作者強調，此模式的成本只有在邊界具有真實法律或風險意義時才值得承擔。隨著 EU Data Act 自 2025 年 1 月 11 日全面適用、英國 Data Use and Access Act 2025 在 2026 年陸續生效，雲原生平台設計者面臨的合規壓力將持續增加，而以 CNCF 生態工具建構的租戶叢集架構提供了一條可依法驗證的技術路徑。
Docker 加入 Athena 聯盟：跨產業協作應對 AI 加速的供應鏈攻擊
Docker Blog · 2026-06-15
Docker 於 2026 年 6 月 15 日宣布加入 Athena 聯盟，這是一個由 Chainguard 主導發起、旨在跨組織協調開源軟體漏洞防禦的跨產業安全倡議。Athena 的核心目標是在漏洞公開披露前，透過成員間的即時信號共享來協調應對措施，以縮短從漏洞發現到遭利用（weaponization）之間的視窗期。
背景
Athena 聯盟的成立源於一個具體的威脅趨勢：前沿 AI 模型可以比人類安全研究員更快地發現漏洞，使得傳統的「負責任披露（responsible disclosure）」流程在時間壓力下逐漸失效。過去漏洞從發現到被武器化（weaponized exploit）的週期可能長達數年，如今已縮短至數小時。聯盟的現有成員除 Docker 外，還包括 Socket（依賴項分析）、Chainguard（映像安全）、Checkmarx（供應鏈分析）及 Aikido（漏洞掃描）。
文章引用兩個具體案例說明協作必要性：2026 年的 Axios 套件遭入侵事件中，聯盟成員跨公司邊界進行即時信號共享，縮短了應對時間；在 TeamPCP 攻擊活動中，生態系協作有效壓縮了爆炸半徑。
核心改動：Docker 的三項技術貢獻
Docker 以三個既有產品作為其對供應鏈安全生態的具體技術貢獻，並將其整合至 Athena 框架下。
第一項是 Docker Sandboxes，針對 AI 程式碼代理（AI coding agent）的隔離執行環境。每個代理運行於獨立的 microVM 中，擁有各自的核心（kernel）與檔案系統，並採用預設拒絕（deny-by-default）的網路策略，防止受損的依賴套件存取宿主機、憑證或其他工作負載。
第二項是 Docker Hardened Images（DHI）社群版，以 Apache 2.0 授權開源，提供從原始碼重新建構的最小化、低 CVE 映像，具備以下安全屬性：
- SLSA Build Level 3 出處記錄（provenance attestation）
- 已簽署的 Software Bill of Materials（SBOM）
- 以 Alpine 與 Debian 為基礎建構
- 目錄涵蓋超過 3,500 個容器映像及數萬個系統套件
- 支援容器映像、系統套件、Helm chart 及 MCP server
第三項是 Docker MCP Catalog 與 Gateway，提供針對 Model Context Protocol（MCP）server 的可信任目錄與集中式存取管控層。Gateway 提供 secret 封鎖、稽核日誌與已驗證代理連線，解決 AI agent 工具呼叫場景中供應鏈信任問題——即如何確保 AI agent 呼叫的外部工具本身未被竄改或注入惡意行為。
影響範圍
Athena 聯盟的架構意義在於，它試圖將軟體供應鏈安全從「單一廠商自我防禦」轉向「生態系層級的協調防禦」。這與 CNCF 在 SLSA、SBOM 及 Sigstore 等規範上的推動方向一致，但在組織層面新增了跨公司漏洞情報共享機制。
對於依賴開源映像或 AI agent 工具鏈的 DevOps 團隊，Athena 聯盟帶來的直接影響包括：更快速的上游漏洞預警、更廣泛的映像出處驗證覆蓋（透過 DHI），以及在 AI agent 部署場景中更清晰的 MCP server 信任邊界。隨著 AI 輔助開發成為標準工作流，供應鏈攻擊的向量也從傳統 npm/PyPI 套件延伸至 MCP server 與 AI agent 執行環境，Athena 所呼應的正是這一新興威脅面。