Cloudflare 開放 OAuth 自助管理：零停機完成引擎大升級
Cloudflare Blog · 2026-06-24
Cloudflare 於 2026 年 6 月 24 日宣布，所有開發者現已可在 Cloudflare 儀表板自助建立 OAuth 應用程式，無需再等待人工審核。與此同時，該公司也完成了底層 OAuth 引擎從 Hydra 1.X 升級至 2.X 的零停機遷移，並帶來顯著的效能改善。
背景：從封閉夥伴到全面開放
過去，Cloudflare 的 OAuth 功能僅限少數手動審核的合作夥伴使用，一般開發者若想建立整合應用，必須走繁瑣的申請流程。2026 年 6 月 3 日的變更紀錄標誌著轉折點：Self-Managed OAuth Clients 正式向所有人開放，讓開發者可自行在 Dashboard 建立第三方應用程式，取代過去依賴 API Token 的整合方式。
應用程式初始為私有（僅帳號成員可見），經過網域驗證後可公開上架，使用者在授權頁面上能看到「已驗證」徽章。典型用例之一是讓 Wrangler CLI 代表用戶部署 Workers，整個流程走標準 OAuth 授權，無需用戶直接暴露 API 金鑰。
核心改動：Hydra 引擎零停機升級
OAuth 功能的全面開放，有賴底層引擎的高可用穩定性。Cloudflare 以藍綠部署（Blue-Green Deployment）為基礎，分兩個階段完成 Hydra 升級：先從 1.X 升至中間版本，再升至 2.X，整個過程對外服務不中斷。
最大挑戰在於資料庫 schema 遷移。傳統方式需要對關鍵資料表加排它鎖，在高流量的生產環境下不可接受。工程團隊採用 CREATE INDEX CONCURRENTLY 搭配對 Hydra 原始碼的客製修改，繞開了鎖定問題。令牌撤銷事件的遺失則透過 Cloudflare Queues 建立佇列緩衝機制解決，切換期間暫存所有撤銷請求，切換完成後重放至新引擎。
此外，在 Workers 層加入了 refresh token 合併（Coalescing）邏輯，防止重試請求導致 session 意外失效，確保切換視窗期間用戶端不會被登出。
規格細節：遷移規模與效能數字
此次遷移共處理了 132.5M 筆資料列，臨時資料量達 136.97 GB，整個生產執行時間約 3 小時。升級完成後，效能改善如下：
- API P95 延遲：
185ms → 101ms（降低 45%） - RSS 記憶體：
888MB → 763MB（降低 14%） - CPU 使用率：
1.07 → 0.67 cores（降低 37%）
Hydra 2.X 本身的記憶體與 CPU 優化是效能改善的主因，加上舊版累積的技術債一併清除，整體資源佔用大幅下降。
影響範圍
對想與 Cloudflare 平台整合的開發者而言，這次開放意味著無需等待審核即可立即開始建立 OAuth 應用，入口位於 Cloudflare Dashboard 的 OAuth Clients 區段。對於企業維運團隊，Hydra 引擎升級所帶來的延遲與資源改善可直接降低基礎設施成本，並提升授權流程的回應速度。第三方應用若已使用 API Token 與 Cloudflare 整合，也可評估遷移至 OAuth 以改善稽核追蹤與細粒度授權控制。
原始來源：Cloudflare Blog — Unlocking the Cloudflare app ecosystem with OAuth for all、Cloudflare Changelog — Self-Managed OAuth Clients (2026-06-03)
Kubernetes 硬體管理大躍進：DRA 在 v1.35 正式 GA，AI 與邊緣運算的新基礎
Kubernetes Blog · 2026-06-24
Kubernetes 官方部落格於 2026 年 6 月 24 日聚焦介紹 Device Management 工作組（WG），並確認其核心成果——Dynamic Resource Allocation（DRA）——已在 Kubernetes v1.35 正式升級為 GA（Generally Available）穩定功能，預設啟用。這項變更為 AI 訓練、邊緣運算與電信工作負載中 GPU、TPU、FPGA 等硬體資源的調度，建立了全新的標準化架構。
背景：舊模型的根本局限
在 DRA 出現之前，Kubernetes 對設備資源的抽象極為簡化：設備被視為整數計數器，無法表達 GPU 記憶體大小、互連拓撲、時間共享（Time-Sharing）等細粒度特性。當 AI 工作負載需要動態分配硬體或在 Pod 啟動後變更資源組態時，舊有的 Device Plugin 機制無法應對，調度問題甚至升級為 NP-hard 複雜度。
WG Device Management 工作組在 KubeCon EU 2024（巴黎）正式成立，由 NVIDIA 的 Kevin Klues、Intel 的 Patrick Ohly 及 Google 的 John Belamaric 共同擔任 Co-Chair。DRA 的概念雛形早在 2019–2020 年便已存在，但 2023 年 AI 熱潮後才真正加速推進，並在解決 Autoscaler 相容性疑慮後獲得社群廣泛支持。
核心改動：DRA 的四階段框架
DRA 以 resource.k8s.io/v1 API 群組為核心，提供四個階段的硬體管理流程：
- 建模（Modeling）：硬體廠商驅動程式透過
ResourceSliceAPI 向叢集宣告設備能力與屬性 - 請求（Requesting）：使用者透過
ResourceClaim或ResourceClaimTemplate聲明所需硬體規格 - 調度（Scheduling）：Kubernetes 調度器讀取 ResourceSlice，將 ResourceClaim 與實際節點上的可用設備進行比對
- 啟動（Actuation）：kubelet 協調驅動程式，完成設備準備與安全隔離後再啟動 Pod
Common Expression Language（CEL）的引入是關鍵設計選擇。DeviceClass 資源可透過 CEL 表達式對設備屬性進行細粒度篩選，例如比對顏色、尺寸或自訂標籤，避免了靜態硬編碼的設備選擇邏輯。
規格細節：v1.35 穩定 API 與 v1.36 新功能
在 v1.35 中，以下四個 API Kind 進入穩定（Stable）狀態：
| API Kind | 用途 |
|---|---|
DeviceClass | 定義設備類別與 CEL 篩選規則 |
ResourceClaim | Pod 對特定設備的存取請求 |
ResourceClaimTemplate | 自動為每個 Pod 生成獨立的 ResourceClaim |
ResourceSlice | 設備驅動程式宣告節點上可用資源 |
v1.36 新增了優先列表（Prioritized List）功能，允許在 ResourceClaimTemplate 中定義備選設備請求序列。當第一優先的設備類型（如高效能 GPU）無法調度時，調度器自動嘗試次優選項，有效提升叢集資源利用率：
apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
spec:
spec:
devices:
requests:
- name: req-0
firstAvailable:
- name: large-gpu
deviceClassName: gpu.example.com
selectors:
- cel:
expression: >-
device.attributes["driver.example.com"].size == "large"
- name: small-gpu # 備選：large-gpu 無法調度時使用影響範圍
DRA GA 對平台工程師與 MLOps 團隊的影響是直接的：GPU 等加速器資源的調度不再需要依賴各廠商各自實作的 Device Plugin，轉而使用統一的標準 API，降低了多廠商硬體混搭叢集的維運複雜度。Autoscaler 也能更精確地感知硬體資源狀態。仍在 Alpha 階段的功能包括可分割設備（Partitionable Devices）、消耗性容量（Consumable Capacity）及設備汙點與容忍（Device Taints and Tolerations），預計在後續版本逐步推進至穩定。
原始來源：Kubernetes Blog — WG Device Management Spotlight 2026、Kubernetes Docs — Dynamic Resource Allocation (v1.35 stable)
軟體成分表 SBOM：從合規要求到供應鏈防禦的實戰指南
Docker Blog · 2026-06-23
Docker 官方部落格於 2026 年 6 月 23 日發布深度說明，解釋什麼是 SBOM（Software Bill of Materials，軟體成分表）、為何它正從「最佳實踐」升格為法律強制要求，以及如何在 Docker BuildKit 環境中以一行指令生成符合標準的 SBOM。美國行政命令 EO 14028 與歐盟網路韌性法（EU CRA）的雙重監管壓力，正在推動整個軟體產業快速補齊這塊安全拼圖。
背景：為何供應鏈安全需要成分表
SBOM 的概念類比食品的「營養標示」，要求軟體提供一份機器可讀的清單，涵蓋每個元件的名稱、版本、供應商、授權條款、相依關係，以及可供驗證的加密雜湊值。SolarWinds 與 Log4Shell 事件揭示了組織往往對自己部署的軟體裡包含哪些第三方元件一無所知的殘酷現實。
根據調查數據，73% 有生成 SBOM 的組織表示漏洞應對效率明顯提升，但 86% 認為生成過程仍具挑戰。約 65% 的開源 CVE 缺乏 NVD 指派的 CVSS 評分，使得僅依賴被動掃描工具的策略愈發不可靠。
核心改動：兩大標準格式的定位差異
SBOM 生態中目前有兩個主流格式，定位與應用場景有所不同：
| 格式 | 主要焦點 | 治理組織 | 適用場景 |
|---|---|---|---|
| SPDX | 授權合規、開源稽核 | Linux Foundation（ISO/IEC 5962:2021） | Docker BuildKit 原生支援 |
| CycloneDX | 安全漏洞管理 | OWASP Foundation | DevSecOps 流水線、CI/CD 整合 |
Docker BuildKit 的 SBOM 生成預設採用 SPDX 格式，以 JSON 編碼附加為 in-toto Attestation，儲存於映像的 OCI Attestation Manifest 中。底層掃描引擎使用 Anchore 的 Syft 工具，並支援替換為自訂掃描器。
規格細節：一行指令生成 SBOM
在 Docker BuildKit 環境下，生成並推送含 SBOM 的映像僅需：
# 建構映像並附加 SBOM Attestation
docker buildx build \
--tag myapp:1.0 \
--attest type=sbom \
--push .
# 簡寫語法
docker buildx build --tag myapp:1.0 --sbom=true --push .預設情況下，BuildKit 僅掃描最終建構階段（final stage）。若需要擴大掃描範圍，可在 Dockerfile 中宣告以下建構參數：
BUILDKIT_SBOM_SCAN_CONTEXT=true：將建構上下文（build context）中的成品納入掃描BUILDKIT_SBOM_SCAN_STAGE=true：對特定或所有中間建構階段進行掃描
一份典型的 SPDX 元件記錄包含套件名稱、版本、供應商、授權類型，以及 SHA-256 校驗值：
{
"name": "openssl",
"SPDXID": "SPDXRef-Package-openssl",
"versionInfo": "3.1.4",
"supplier": "Organization: OpenSSL Project",
"licenseDeclared": "Apache-2.0",
"checksums": [{ "algorithm": "SHA256", "value": "a1b2c3..." }]
}影響範圍：監管要求正在加速
美國行政命令 EO 14028 要求出售給聯邦機構的軟體必須提供 SBOM；CISA 在 2025 年發布的最低要求指南進一步明確了細節；歐盟《網路韌性法》（EU CRA）則將規範延伸至歐洲市場銷售的產品。對於維運團隊而言，SBOM 最直接的價值在於事件應對速度：當新 CVE 出現時，可在秒級而非數日內確認哪些映像受影響，並快速決定修補優先順序。
Docker Scout 的持續漏洞監控即以 SBOM 資料為基礎；Docker Hardened Images 則出廠附帶完整 SBOM 與 SLSA Build Level 3 來源證明，提供開箱即用的供應鏈透明度。需特別留意的是，SBOM 不等同於 SCA（軟體組成分析）工具——SBOM 是清單本身，SCA 工具是掃描清單找出漏洞的執行者，兩者搭配才能構成完整的縱深防禦。
原始來源：Docker Blog — What is an SBOM (and Why Can't You Ship Without One)?、Docker Docs — SBOM attestations with BuildKit