Packer 1.16 補上映像檔可驗證來源、Dragonfly 甩開資料庫做 P2P 佈署、Docker 定義 Agent 安全基線
hashicorp.com、cncf.io、docker.com · 2026-08-13
三則各自獨立的公告,合起來勾勒出同一條主軸:基礎設施與自動化系統的信任鏈,愈來愈需要可驗證的紀錄而非口頭承諾。HashiCorp 讓 Packer v1.16.0 內建映像檔來源簽署與驗證;CNCF 部落格介紹 Dragonfly 拿掉資料庫也能做 P2P 鏡像分發;Docker 則與 Snyk、Keycard 聯合發布 Agent Baseline,為企業導入 AI Agent 訂出六項安全成果指標。
Packer 1.16:用 SLSA 供應鏈溯源簽署映像檔
Packer v1.16.0 加入原生的 SLSA provenance attestation 產生、簽署與驗證功能,官方稱其提供「不需額外工具就能得到的、防竄改的建置紀錄」。攻擊面在於映像檔從建置到部署之間的空白,若無法證明某個 AMI 或 VM 映像確實出自預期的原始碼與流水線,攻擊者插入的惡意映像就難以被攔截。attestation 採用 in-toto statement 包裝 SLSA Provenance v1 predicate,記錄 Git commit、repo、ref、CI 觸發來源、建置時間、產物 SHA-256 digest、builder ID 等中繼資料。
簽署模式分四級:none(不簽署)、key(本機 PEM 私鑰)、kms(雲端 KMS 或 HashiCorp Vault)、keyless(透過 Sigstore Fulcio,可選寫入 Rekor 透明日誌)。驗證則靠新指令收尾這條鏈,部署前執行 packer verify-attestation 即可檢查簽署身份、產物 digest 與 Rekor 紀錄是否吻合。依簽署方式不同,建置可對應到 SLSA Build Level 1 到 3:L1 只要有簽署過的 provenance,L2 需由代管服務(如 CI 平台的 keyless 模式)產生並簽署,L3 則要求建置過程本身是隔離環境產出。
packer build -provenance=keyless template.pkr.hcl
packer verify-attestation image.raw.jsonDragonfly:拿掉 MySQL 與 Redis 的輕量 P2P 佈署
CNCF 專案 Dragonfly 一直是 Kubernetes 叢集裡常見的容器映像 P2P 分發方案,用節點間互傳分片取代每個節點各自向 registry 拉取全量鏡像。但過去佈署 Dragonfly 得先立起一套 Manager 控制平面,外加 MySQL 與 Redis,對中小型叢集是不小的維運負擔。官方部落格說明的輕量部署模式,直接用 Kubernetes 原生的 ConfigMap 取代 Manager 存放動態設定(dynconfig.yaml),再用 Headless Service 讓 Scheduler 之間靠 DNS 互相探索與健康檢查。
整套架構只留三種元件:以 StatefulSet 跑的 Scheduler 負責排程與分片調度,以 StatefulSet 跑的 Seed Client 作為向來源倉庫拉取的根節點,以 DaemonSet 跑在每台節點上的 Client 則把容器鏡像拉取請求導向本機的 P2P 對等端。省掉的是資料庫的備份與遷移腳本,設定變更透過 ConfigMap 更新,預設一分鐘內就會同步到所有 Pod;需要持久化任務記錄時仍可選擇性加回 Redis,叢集成長後也能無痛升級回完整的 Manager 架構。相關程式碼在 dragonflyoss/dragonfly 與 dragonflyoss/client 兩個 repo。
Docker Agent Baseline:企業導入 AI Agent 的六項安全成果
Docker 與 Snyk、Keycard 共同發布的 Agent Baseline,是一套定義企業建置、運行與治理 AI Agent 時應達到的最低安全成果的公開藍圖,v1.0 草案共列出 35 項控制項,分屬六大成果。問題根源在於 Agent 可在執行期被自然語言指令重新賦予任務,且常橫跨多個系統以被授權的身份行動,傳統以靜態角色與權限為核心的存取控管因此不夠用。六項成果分別是:
- Discover:對每個 Agent 的擁有者、用途、元件、依賴與有效存取權維持準確紀錄。
- Constrain:把 Agent 的執行環境、資料、工具、網路可達範圍、算力與時長限制在其被核准用途所需的範圍內。
- Authorize:讓具實質影響的動作綁定明確的身份、任務、目標、範圍與有效期間。
- Observe:用穩定的 run 或 trace ID 把意圖、身份、政策、工具使用、動作與結果串起來。
- Validate:在 Agent 實際運行的設定與環境中測試它,再驗證其輸出與結果。
- Respond:能夠停止 Agent、撤銷其權限、隔離受影響元件、保存證據並判斷影響範圍。
控制項細節可在 agentbaseline.org/controls 查到,例如 Constrain 底下要求「在與主機、不相關專案、憑證及其他工作負載隔離的、風險相符的邊界內執行 Agent 程式碼」,Respond 底下則明確提到要防範「對 Agent 元件的抽梯式(rug-pull)變更」。這份藍圖不綁定特定廠商工具,設計上是讓企業拿它去對照現有的 Agent 平台或治理流程,檢查缺口在哪。