Docker Hardened Images 整合 Aikido：以 VEX 機制自動過濾不可利用漏洞
Docker Blog · 2026-06-11
Docker 於 2026 年 6 月 11 日宣布，Docker Hardened Images（DHI）已與安全掃描平台 Aikido 完成整合，透過 OpenVEX（Vulnerability Exploitability eXchange）標準，自動抑制已確認為不可利用的 CVE，大幅減少安全團隊需手動處理的誤報數量。此整合覆蓋所有托管於 Docker Hub 的 DHI 映像，無需使用者額外配置掃描規則。
背景
DHI 是 Docker 推出的一系列最小化、高安全性容器基礎映像。以 Python 3.13 為例，DHI 版本的映像大小僅 35 MB，內含 80 個套件；相較之下，標準映像為 412 MB、610 個套件，且移除後者存在的 1 個高危、5 個中危、141 個低危及 2 個未分類 CVE。DHI 的設計目標是「接近零 CVE」的映像基線，並附帶已簽署的 SBOM（Software Bill of Materials）供下游工具使用。
然而，即使是 DHI，在第三方掃描器眼中仍可能出現大量 CVE 誤報——這些 CVE 在技術上存在於套件中，但由於映像配置或使用情境，實際上無法被利用。傳統掃描流程缺乏區分「存在」與「可利用」的機制，導致安全工程師需耗費大量時間進行人工分類。
核心改動
Aikido 整合的核心流程分為四個階段。首先，Aikido 透過映像 reference 及 registry metadata 自動識別 DHI 基礎映像，無需使用者標記。接著，工具透過 OCI 1.1 referrer lookup 或直接讀取映像內的 /opt/docker/sbom/ 路徑，取得 Docker 簽署的 SPDX 2.3 格式 SBOM。
元件匹配階段使用 PURL（Package URL）格式，將 SBOM 中的套件對照 Docker OSV feed 及上游 advisory 資料庫進行比對。最後，VEX 應用階段根據 OpenVEX statement 的狀態欄位，自動抑制特定發現：
fixed：漏洞已在映像中修補not_affected：CVE 確認為誤報或不可利用，自動抑制under_investigation：影響範圍仍在評估中affected：漏洞確認存在，尚無修補
使用者只需在 Aikido 的 Settings > Containers 介面連接 Docker Hub registry（需提供 read-only 範圍的 Personal Access Token），執行一次 Scan repos in registry 後，DHI 偵測與 VEX 套用即全自動完成。
影響範圍
此整合對於已採用 DHI 作為基礎映像並使用 Aikido 進行容器掃描的團隊影響最為直接：掃描報告中原本需要人工逐一確認的大量「存在但不可利用」CVE，將直接被過濾，安全分類工作量理論上可大幅下降。對於尚未採用 DHI 的團隊，此次整合同時也是評估從標準映像遷移至 DHI 的契機——移除數百個套件與 CVE，是降低攻擊面最直接的方法。
值得注意的是，OpenVEX 與 SPDX 2.3 均為開放標準，DHI 的 VEX attestation 原則上也可被其他支援這些標準的掃描工具（如 Grype、Trivy）所利用，但各工具的實際支援程度仍需個別驗證。
Grafana Tempo 3.0：Kafka 驅動的讀寫分離架構與 TraceQL Metrics 正式發佈
Grafana Blog · 2026-06-01
Grafana 於 2026 年 6 月 1 日正式發佈 Tempo 3.0.0，這是該分散式追蹤後端自開源以來規模最大的架構重構。核心變更為引入 Kafka 相容的寫入緩衝層（內部代號 Project Rhythm），徹底移除 ingester 元件，同時將 TraceQL metrics 功能從實驗性升至正式可用（GA）。此版本在 microservices 部署模式下破壞性變更較多，monolithic 模式則維持原有架構不變。
原本的問題
Tempo 舊架構的寫入路徑依賴 ingester 元件，預設使用 Replication Factor 3（RF3）——即每份追蹤資料同時存放三份副本以確保持久性。RF3 顯著提高了物件儲存（object storage）的成本，且 ingester 在高流量場景下容易成為瓶頸。此外，讀寫路徑緊耦合，使得獨立擴展各元件的彈性受限。
TraceQL metrics 在 2.x 時代依賴 metrics-generator 元件，需要額外部署並維護其生命週期，且無法直接對歷史追蹤資料執行臨時（ad-hoc）指標查詢。這對於需要在同一介面同時分析追蹤與衍生指標的工程師而言，操作流程較為繁瑣。
採用的方法
3.0 的 microservices 架構以 Kafka 相容訊息佇列作為讀寫之間的持久性緩衝層。Distributor 直接將追蹤資料寫入 Kafka topic，取代原本寫入 ingester 的路徑。新增的 block-builder 元件從 Kafka 消費資料，並將 Parquet 格式的 block 寫入物件儲存；live-store 元件則負責服務尚未落入 block 的最近追蹤資料。compactor 元件由 backend scheduler 與 worker 取代，負責排程壓縮任務。
此架構使得物件儲存可改為單副本（RF1）存放，直接降低三分之二的儲存費用。metrics-generator 亦改為從同一 Kafka topic 消費資料，無需另行接收追蹤流量。新的 block 格式 vParquet5 將每個 scope 可配置的專用字串欄位數從 10 增至 20，並新增最多 5 個整數欄位，加速屬性搜尋效能。
TraceQL metrics GA 後，不再依賴 metrics-generator：
# 使用比較運算子進行閾值查詢（3.0 新增）
{ span:name = "GET /:endpoint" } | avg_over_time(span:duration) > 1s新增的比較運算子（>、<、>=、<=、!=）讓工程師可直接從追蹤資料中提取 SLO 相關指標，近期查詢由 live-store 服務，歷史資料由 RF1 block 提供。
3.0 同步推出 trace 資料脫敏功能，透過新的 CLI 指令觸發 gRPC 後端任務：
tempo-cli redact --tenant=STRING --trace-id=TRACE-ID <scheduler-addr>此外，MCP server 支援也在此版本中加入，可透過 --query-frontend.mcp-server.enabled=true 旗標啟用。
影響範圍
升級至 3.0 對 microservices 模式部署者影響重大，需在升級前完成以下準備：
- 移除所有 ingester 及 compactor 相關配置、CLI 旗標、告警與 dashboard
- 使用
tempo-cli migrate config自動轉換 2.x 配置 - 將 legacy overrides 以
tempo-cli migrate overrides-config轉換（保留舊格式 Tempo 將拒絕啟動） - 從 OpenCensus receiver 遷移至 OTLP
- 注意
!=與!~運算子語義變更：前者現為 NOT IN（原為 CONTAINS NOT EQUAL）
Monolithic 模式部署者無需引入 Kafka，現有配置基本相容，僅需執行配置遷移工具即可完成升級。v2 block 格式已棄用，但現有 v2 block 仍可讀取，直至後續版本正式移除。
Kubernetes Dashboard 正式封存，Headlamp 接棒成為官方推薦 UI
Kubernetes Blog · 2026-06-01
Kubernetes Dashboard 專案已正式封存（archived），Headlamp 於 2026 年 6 月成為 Kubernetes 社群官方推薦的叢集視覺化介面。Headlamp 由 Kubernetes SIGs 社群維護，最新版本為 0.43.0（2026 年 6 月 16 日發佈），提供插件架構、多叢集支援及桌面應用程式模式，定位超越傳統 Dashboard 的功能邊界。
原本的問題
Kubernetes Dashboard 作為最早期的官方 UI，架構設計上僅支援單一叢集，且可擴展性有限。隨著企業環境中多叢集拓撲（開發、測試、正式環境各自獨立叢集）成為主流，Dashboard 無法在同一介面管理多個叢集的缺陷日益明顯。此外，Dashboard 缺乏插件機制，第三方工具若需在 UI 層整合（如顯示 cost metrics、GitOps 狀態），只能 fork 或另行開發獨立介面，維護成本高。
另一個長期問題是部署彈性不足：Dashboard 主要設計為 in-cluster 部署，對於需要在本機環境直接存取遠端叢集的開發者而言，配置相對繁瑣。安全模型設計亦較為陳舊，無法原生支援現代 OIDC provider（如 Entra ID、Okta）的認證流程。
採用的方法
Headlamp 在核心功能上完整覆蓋 Dashboard 的操作流程：Pod、Deployment、Service、Namespace 的瀏覽與操作、基於 RBAC 權限的資源 manifest 直接編輯、工作負載縮放與刪除，均保持一致的使用體驗。遷移設計以連續性為優先，具備 Dashboard 使用經驗的工程師無需重新學習操作概念。
架構層面，Headlamp 採用插件系統作為核心擴展機制。開發者可透過 registerProjectApiResource() API 註冊自訂 CRD 資源頁面，讓第三方工具在不 fork 主專案的情況下擴展 UI 功能。部署選項包含兩種模式：
- In-cluster 部署：以 Pod 形式運行於叢集內，透過瀏覽器存取，支援 service account token 及 proxy 認證
- 桌面應用程式：以 Electron 打包，讀取本機 kubeconfig，適合本機開發工作流
多叢集支援是 Headlamp 相對於 Dashboard 最關鍵的架構差異：使用者可在單一介面中切換並同時監控多個叢集，涵蓋不同環境的 namespace 與工作負載。0.43.0 版進一步加入 ClusterProfile discovery（透過 Cluster Inventory API，目前為 alpha），為自動化叢集清單管理奠定基礎。
認證方面，Headlamp 0.43.0 新增 OIDC 改進，支援 Entra ID 與 Okta 等公有 provider，並加入 proxy 認證模式供中介層（middleware-based）認證架構使用。前端型別檢查時間在此版本從 18–20 秒降至 3–4 秒，改善了插件開發的迭代速度。
實際效果
對於仍在使用 Kubernetes Dashboard 的團隊，官方封存意味著後續將不再接收安全修補或功能更新，遷移至 Headlamp 應列入近期規劃。現有 Dashboard 的所有核心操作在 Headlamp 中均有對應，遷移主要工作在於重新部署 Headlamp 元件及配置認證機制，而非重新培訓使用者。
對於已有插件開發需求的團隊，Headlamp 的插件 API 相對成熟，可在不修改核心程式碼的前提下整合自訂 CRD、外部指標或 GitOps 工具。Headlamp 的 Windows Arm64 桌面版本亦於 0.43.0 正式加入，擴大了桌面部署的硬體覆蓋範圍。