供應鏈攻擊如何借道 AI Coding Agent 偷走憑證：Docker Sandboxes 的隔離解法
Docker Blog · 2026-07-28
Docker 官方部落格於 2026 年 7 月 28 日刊出《Coding Agent Horror Stories》系列第四篇文章，作者為 Docker Developer Advocate Ajeet Singh Raina。文章以 2025 年 8 月爆發的 s1ngularity 供應鏈攻擊為主軸案例，說明惡意套件如何劫持本機安裝的 AI coding agent 來搜刮開發者機器上的憑證，並介紹 Docker Sandboxes 如何把攻擊面收斂到單一 workspace 內。
原本的問題
根據文中引用的 GitGuardian State of Secrets Sprawl 2026 報告，2025 年被推上公開 GitHub 的硬編碼密鑰達到 2,900 萬筆，年增 34%；AI 輔助寫出的程式碼外洩憑證的機率約為 GitHub 平均值的兩倍。s1ngularity 事件的起點是惡意版本的 npm 套件 nx，其 post-install hook telemetry.js 會先掃描機器上是否裝有 Claude Code、Gemini CLI 或 Amazon Q。
一旦偵測到這些工具，腳本會用權限繞過旗標直接呼叫它們，跳過原本要求人工確認的互動關卡：
const cliChecks = {
claude: { cmd: 'claude', args: ['--dangerously-skip-permissions', '-p', PROMPT] },
gemini: { cmd: 'gemini', args: ['--yolo', '-p', PROMPT] },
q: { cmd: 'q', args: ['chat', '--trust-all-tools', '--no-interactive', PROMPT] }
};被餵入的 prompt 會指示 agent 從 $HOME、.config、.local/share 等路徑遞迴搜尋 .env、id_rsa、錢包 keystore 等檔案，再把路徑與內容 base64 編碼後推上受害者帳號下新建的公開 repo。這起事件最終從 1,079 個受感染 repository 中揪出 2,349 組不同的外洩憑證，事後分析時仍有超過 1,100 組處於有效狀態。攻擊之所以成立，關鍵在於 agent 是以開發者本人的檔案權限在跑，能直接碰到整個家目錄。
採用的方法
Docker Sandboxes 的做法是把 agent 丟進獨立的 microVM，各自擁有自己的 kernel、檔案系統，且網路預設全部拒絕。VM 內部只能看到目前的 project workspace，家目錄以外的個人設定（~/.ssh、~/.aws、工作區外的 .env）在設計上就不會出現在容器裡，等於直接拿掉了 s1ngularity 腳本要遞迴掃描的目標。
第二層防護是代理注入式憑證：真正的密鑰留在主機 OS 的 keychain，VM 內只看得到 placeholder。設定方式如下：
echo "$ANTHROPIC_API_KEY" | sbx secret set -g anthropic
echo "$(gh auth token)" | sbx secret set -g github
sbx run claude在 sandbox 內部讀取環境變數時，看到的是 proxy-managed 這類哨兵字串，真正的憑證只在對外請求送出的那一刻，於網路邊界被動態注入，agent 本身從未持有過明文密鑰。文章也提到可搭配 1Password 在 sandbox 啟動時即時解析憑證，全程不落地寫入主機或 guest 的磁碟。
實際效果
兩種模型的差異可以整理成下表，重點在於即便惡意腳本成功執行，也找不到可偷的東西：
| 面向 | 傳統設定 | Docker Sandboxes |
|---|---|---|
| 憑證存放位置 | agent 碰得到的 .env / 設定檔 | 主機 OS keychain |
| agent 手上拿到的值 | 明文密鑰 | 哨兵 placeholder |
| agent 看得到的檔案系統 | 整個家目錄 | 僅限 project workspace |
| 審計方式 | 外洩後事後掃描 | sbx policy log 即時記錄 |
文中同時列出幾項可立即套用的實務建議：不要把憑證檔案直接交給 agent、只給 workspace 而非整台機器、把裝在本機的 AI CLI 一律當成高權限自動化工具看待、且權限繞過旗標只該在有邊界保護的 sandbox 裡使用。
原始來源：Docker Blog、GitGuardian State of Secrets Sprawl 2026、Docker Sandboxes 文件
Kubeflow 衝刺 CNCF 畢業：一口氣補齊 notebook、pipeline 與分散式訓練的雲原生元件
CNCF Blog · 2026-07-28
CNCF 官方部落格於 2026 年 7 月 28 日發布文章，說明 Kubeflow 專案在正式提出 CNCF Graduation 申請的同時，同步釋出一批鎖定正式環境機器學習工作流的雲原生元件更新。內容涵蓋 notebook 管理、pipeline 建置工具、統一 SDK 與分散式訓練框架四大塊，對應 Kubeflow Community Distribution 26.03.1 版本。
原本的問題
Kubeflow 長期以來由多個各自獨立演進的子專案組成，資料科學家要跑完一次訓練流程，往往得自行拼裝 notebook、pipeline 工具與訓練框架，介面與設定方式互不一致。文章指出這種碎片化增加了平台團隊統一治理的難度，也讓資料科學家的日常使用摩擦成本偏高。這正是本次更新想解決的核心痛點。
採用的方法
Kale 2.0 讓開發者可以直接把標註過的 Jupyter notebook 轉換成正式可跑的 Kubeflow Pipelines，不需要另外寫 SDK 程式碼，並更新支援 Kubeflow Pipelines v2（KFPv2）架構。Kubeflow Notebooks v2 則把原本的 notebook 管理方式改成宣告式、CRD 驅動的架構，統一管理 JupyterLab、RStudio、VS Code 等互動式環境，目前為 Alpha 版本，GA 在路上。
Kubeflow SDK 把資料處理、pipeline 編排、分散式訓練與超參數調校整合進單一開發介面，新增原生 Spark Connect 支援，也內建 LLM fine-tuning 的 blueprint 範本降低起手成本。Kubeflow Trainer 則透過 MPI 支援涵蓋分散式訓練與 HPC 工作負載，目前有 Hyperparameter Optimization Job、以及 GRPO、PPO 等強化學習演算法的提案正在進行中。
本次 Community Distribution 26.03.1 綁定的各元件版本如下：
- Kubeflow Pipelines
v2.16.0 - Spark Operator
v2.5.0 - Model Registry
v0.3.5 - Trainer
v2.2.0 - Notebooks
v1.11 - KServe Web Application
v0.18.0
實際效果
Kubeflow 目前狀態是已正式提出 CNCF Graduation 申請，尚未完成畢業，仍處於朝向這個更高成熟度等級推進的階段——CNCF 專案成熟度由低到高分為 Sandbox、Incubating、Graduated 三級，畢業代表治理結構、採用廣度與安全稽核都通過 CNCF 委員會檢視。文章同時提到社群端的配套動作，包括 Outreach Program 的每月導師會議、ML Experience Working Group 專注降低採用門檻，以及訂於 8 月 19 日 15:00 GMT 舉行的 Community Showcase 2026，展示 GenAI 與 MLOps 的實際落地案例。
原始來源：CNCF Blog、Kale 2.0 Release、Kubeflow Manifests 26.03 Release
用 Linkerd Multicluster 做叢集聯邦：整座 Kubernetes 叢集掛掉也能零停機
CNCF Blog · 2026-07-27
CNCF 官方部落格於 2026 年 7 月 27 日刊出文章，作者為 CNCF Ambassador、Linkerd 貢獻者 Dominik Táskai。文章說明如何用 Linkerd 的 multicluster extension 把多個 Kubernetes 叢集聯邦成單一服務拓撲，讓其中一整座叢集失效時流量能自動轉移，不需要人工介入改設定。
原本的問題
單一 Kubernetes 叢集本身就是一個故障單位：無論是雲端區域中斷、控制平面出問題，還是維運失誤，只要那座叢集掛了，跑在裡面的服務就整個下線。要做到跨區域容錯，過去得自己在應用層寫服務發現、健康檢查與流量切換邏輯，維運複雜度高且容易出錯。文章要解決的正是叢集層級的零停機容錯問題。
採用的方法
Linkerd multicluster 提供三種可透過 Kubernetes label 切換的模式。Federated 模式用 mirror.linkerd.io/federated=member 標記，把不同叢集中同名的服務合併成單一 <svc>-federated endpoint，自動在所有叢集副本間做負載平衡。Flat Mirroring 用 mirror.linkerd.io/exported=remote-discovery，服務會以 <svc>-<cluster> 的形式出現，直接走 pod-to-pod 流量，前提是網路本身是扁平連通的。
Gateway Mirroring 則用 mirror.linkerd.io/exported=true，流量改走 Linkerd gateway 轉送，即使叢集間網路不是扁平的也能互通。跨叢集的 mTLS 信任模型建立在共用 root CA、各叢集各自簽發 issuer 憑證之上；文中示範的三叢集環境採全網狀（full-mesh）串接，等於要建立六條有方向性的連線。VPC 對等連線需要加上 --export-custom-routes 與 --import-custom-routes 旗標，且各叢集的 CIDR 範圍不能重疊，否則對等路由會直接衝突。
實際效果
文章描述的 chaos test 中，主動關掉其中一座叢集後，Federated 服務呈現「自動重新平衡、零錯誤」的結果——原文寫道流量在叢集故障後幾秒內就完成重新分配，過程中沒有錯誤，也不需要改動任何設定。這代表故障切換的邏輯完全下沉到 service mesh 層，應用程式本身不需要感知到叢集層級的故障事件。文章附上的 GitHub 範例庫提供了在三個地區的 GKE 叢集上落地這套架構的部署腳本。
原始來源：CNCF Blog、Linkerd Multicluster 文件、Federated Services 任務指南