Gateway API v1.6 發布：TCPRoute 與 UDPRoute 正式畢業至 Standard Channel
Kubernetes Blog · 2026-08-03
Kubernetes Gateway API 專案於 2026 年 8 月 3 日在官方部落格公布 v1.6.0 版本內容。這次更新的重點是 TCPRoute 與 UDPRoute 兩項資源正式從 Experimental 通道畢業至 Standard channel。兩者的 API 群組版本從 v1alpha2 升級為 v1，代表它們自此享有生產等級的相容性保證。
核心改動
TCPRoute 與 UDPRoute 分別對應 GEP-2644 與 GEP-2645，由 Nick Young、Ricardo Katz、Zac Nixon 主責推動畢業工作。畢業後兩者改用 gateway.networking.k8s.io/v1，舊有的 v1alpha2 版本則自本次起標記為 deprecated，將於未來版本中移除。與此同時，仍留在實驗階段的其他資源被移到獨立的 gateway.networking.x-k8s.io API 群組，讓 Standard 與 Experimental 之間的邊界更明確。
| API 資源 | 先前版本 | 本次版本 | 狀態 |
|---|---|---|---|
| TCPRoute | v1alpha2 | v1 | Standard（GA） |
| UDPRoute | v1alpha2 | v1 | Standard（GA） |
畢業後的 TCPRoute 用法維持原本設計：Gateway 開一個 TCP 監聽埠，再由 TCPRoute 依照 parentRefs 與 sectionName 把流量導到後端 Service，本身不具備七層（L7）解析能力，純粹依協定與埠號轉發。UDPRoute 的結構與 TCPRoute 對稱，僅監聽協定改為 UDP。以下為 TCPRoute 的最小設定範例：
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: example-gateway
spec:
gatewayClassName: example-gateway-class
listeners:
- name: foo
protocol: TCP
port: 12345
allowedRoutes:
kinds:
- kind: TCPRoute
影響範圍
畢業至 v1 代表後續版本不會再有破壞性欄位變更，並遵循 Kubernetes 標準的 API 相容性與棄用政策，這對正在評估是否把生產流量的路由規則遷到 Gateway API 的團隊，是一個明確的訊號。過去資料庫連線、DNS、VoIP、遊戲伺服器、IoT 遙測等非 HTTP/TLS 流量，若要用 Gateway API 描述路由規則，只能停留在實驗版本或依賴各家 Gateway 控制器自訂的 CRD。
對正在使用 v1alpha2 TCPRoute/UDPRoute 的叢集，升級規劃需要留意兩件事：物件本身需要遷移到新的 API 版本，同時要確認叢集內的 Gateway 控制器（例如 Envoy Gateway、Istio、Contour 等實作）是否已經支援 v1 版本的 TCPRoute/UDPRoute，避免資源畢業之後控制器端還停留在只認得 v1alpha2 的舊行為。
CNCF 專案 Cortex 完成 OSTIF 資安稽核，7 項發現全數修復
CNCF Blog · 2026-08-03
Cloud Native Computing Foundation 於 2026 年 8 月 3 日在官方部落格宣布，旗下專案 Cortex 已完成一輪資安稽核。Cortex 是提供 Prometheus 與 OpenTelemetry 使用的多租戶、長期可擴展儲存後端。這次稽核由 Open Source Technology Improvement Fund（OSTIF）主導委託，實際評估工作於 2026 年春季由資安顧問公司 Quarkslab 執行。
稽核範圍
OSTIF 是一個長期媒合開源專案與專業資安團隊、協助進行免費或補助式資安稽核的非營利組織；本次實際執行稽核的 Quarkslab 則是專精程式碼審查與滲透測試的資安顧問公司。稽核聚焦在租戶邊界（tenant boundary）安全性與叢集維運操作，逐一檢視這些功能在機密性、完整性、可用性（CIA）三個面向的表現。
- 白箱程式碼審查（whitebox code review）
- 威脅模型分析（threat model analysis）
- 靜態分析（static analysis）
- 動態測試（dynamic testing）
發現與修補
本次稽核總計發現7 項具資安影響的問題，其中 6 項被評為中度（Medium）風險，1 項為低度（Low）風險；公告中並未列出對應的 CVE 編號或個別漏洞名稱。這 7 項發現目前皆已完成修復，且修復結果經過驗證（verified fixes）。
CNCF 官方建議使用者更新至最新版 Cortex，以套用這些修補。除了漏洞修復本身，這次合作也為專案留下客製化文件與後續資安開發建議，作為 Cortex 維護團隊往後強化安全開發流程的參考依據。
Docker AI Governance 新增稽核日誌，AI Agent 決策直送資安團隊慣用的 SIEM
Docker Blog · 2026-08-03
Docker 於 2026 年 8 月 3 日在官方部落格宣布，Docker AI Governance 新增稽核日誌（audit logs）功能，把 AI agent 相關的政策執行結果，直接送進資安團隊原本就在使用的 SIEM 系統。此功能鎖定已啟用 Docker AI Governance 授權、並強制套用組織政策（enforced organization policy）的組織開放使用。
核心改動
- 允許（allowed）：agent 動作通過政策檢查。
- 拒絕（denied）：工具呼叫、網域存取或憑證使用被擋下。
- 轉交人工審核（held for human review）：需要人工核准的動作。
涵蓋範圍包含 Docker Sandboxes 的政策決策與沙盒工作階段（sandbox session）事件，以及正在擴大支援的 MCP Gateway 執行決策。需要留意的限制是，這些紀錄僅到中繼資料（metadata）層級，不包含prompt 內容、agent 輸出結果或實際參數數值本身。
日誌可透過原生串流整合送往 Splunk 與 Dynatrace，也支援透過 generic HTTPS endpoint 串接自建 SIEM；原本寫入本機磁碟的方式仍保留。若集中存放在 Docker Cloud，官方保留 90 天，並提供 CSV 匯出功能。
影響範圍
這項能力綁定在 Docker AI Governance 授權之下，組織必須啟用並強制套用政策才會生效，目的是讓資安團隊把 AI agent 治理紀錄整合進既有的告警與合規流程，不需要另外開一套介面查詢。由於記錄只到 metadata 層級，若要還原被擋下動作的具體參數或完整呼叫內容，仍需搭配應用端自身的日誌來補足。
隨著 MCP Gateway 端的執行決策記錄逐步擴大涵蓋範圍，可預期未來會涵蓋更多 AI agent 與外部工具互動的治理場景，而不只侷限在 Docker Sandboxes。
原始來源：Docker Blog - Docker AI Governance: Audit Logs, Now Where Your Security Team Already Works