CNCF 發布平台工程成熟度模型 v1:五個維度四個等級,量化「自助服務」到底做到了沒
CNCF · 2026-09-01
CNCF 的 Platform Engineering 技術社群小組(TCG)發布了《Platform Engineering Maturity Model》v1 白皮書,把過去只能用「有沒有 Backstage」這種二分法判斷的平台工程成熟度,拆成五個可以獨立評分的維度。這份模型由 Cloud Native Platform Engineering 社群主筆,CNCF 大使 Atulpriya Sharma 在部落格文章中同步說明其設計動機。模型不指定任何具體工具鏈,而是描述組織行為模式,附帶一份線上自評工具。
背景:兩種房間各說各話
文章觀察到平台工程的討論通常分裂成兩群人:還沒有平台的團隊,和已經有平台但不知道下一步往哪走的團隊。缺乏共同量尺是核心問題——一個團隊說「我們有自助服務」可能只是套了一份 Terraform module 範本,另一個團隊說的卻是點一下就能自動佈建、政策即時檢查的完整鏈路。CNCF 這份模型的目的就是把這種模糊的自我認知,轉換成可以逐項比對的矩陣。
核心規格:五維度 × 四等級矩陣
模型定義了 Investment、Adoption、Interfaces、Operations、Measurement 五個面向,每個面向各自獨立評出 Provisional、Operational、Scalable、Optimizing 四個等級。各維度不要求同步前進——文件明確指出一個組織可能在 Interfaces 已達 Scalable,但 Measurement 還停在 Provisional,這是常態而非缺陷。以最貼近討論主題的 Interfaces(使用者如何消費平台能力)為例,四個等級的具體描述如下:
| 等級 | Interfaces 面向的行為特徵 |
|---|---|
| Provisional | 客製化、不一致的流程,需要人工介入,知識靠人傳人 |
| Operational | 標準化工具與「golden path」樣板,文件齊全,但仍需領域專家操作 |
| Scalable | 真正的自助服務,一鍵佈建,客製化空間有限但足夠日常需求 |
| Optimizing | 能力透明嵌入既有工作流程,自動佈建、可組合的建構區塊 |
其餘四個維度採同樣邏輯評分。Investment 從「志願性、無專職預算」一路推進到「跨組織生態系級的能力分散投入」;Operations 從被動回應個案請求,到用 IaC 做合規追蹤,最終走向標準化、自動化的生命週期管理;Measurement 則從「有做調查就不錯了」演進到用產品管理框架蒐集量化與質化數據,文件甚至提醒要留意 Goodhart 定律這類指標失真的風險。
影響範圍
CNCF 同步釋出線上自評工具 pemm-assessment,團隊可以逐維度打分並取得對應等級描述,不需要下載 PDF 比對文字。這份模型定位為既有框架的延伸,銜接先前的 CNCF Platforms White Paper 與 Cloud Native Maturity Model,而非取而代之。白皮書目前提供英文、中文、韓文、日文、西班牙文、法文、德文七種語言版本,顯示 CNCF 有意讓這份矩陣成為跨地區平台團隊溝通現況的共通語言,而不只是英語圈內部文件。
原始來源:CNCF Platform Engineering Maturity Model v1、CNCF Blog、PEMM 自評工具
HashiCorp Boundary 把 TN3270 主機連線也納入 Zero Trust 代理,三種協定各自不同套憑證機制
HashiCorp Developer Docs · 2026-09-01
HashiCorp 在部落格說明 Boundary 如何把既有的 session 代理能力套用到大型主機(mainframe)存取場景。z/OS 環境的管理介面分成兩層:硬體管理主控台(HMC)走 HTTPS,LPAR 內的管理主控台則依情況使用 TN3270/TN3270E、SSH 或 HTTPS。這次的重點不是新版號,而是把三種協定分別接上不同的憑證仲介機制,取代過去常見的共用帳密、VPN 直連做法。
核心機制:worker 反向連線 + 三套憑證策略
架構上,一台跑在主機同網段 Linux 主機上的 Boundary worker 會對 Boundary 控制平面建立加密的 outbound 連線,再把授權過的 session 代理到主機目標,行政人員不需要對主機網段開放 inbound 連線。三種協定各自對應不同的憑證處理方式,細節如下:
| 協定 | Boundary 機制 | 憑證來源 | 是否支援 session recording |
|---|---|---|---|
| SSH(透明 session) | credential injection | Vault 動態 SSH 憑證 | 是,轉存為 asciicast 播放 |
| TN3270 / TN3270E | credential brokering | Vault 動態 RACF passphrase | 否(依官方文件,錄影僅支援 SSH 與 RDP) |
| HTTPS(HMC 主控台) | HTTPS proxy | 依目標設定 | 否 |
值得注意的是官方 session recording 文件明確寫出目前只支援 SSH 與 RDP 兩種協定,錄影會封裝成 BSR(Boundary Session Recording)格式存進 S3 或 MinIO 相容的物件儲存,SSH 逐字稿轉成 asciicast 供瀏覽器內建 player 回放。這代表 TN3270 主機 session 目前只能靠 credential brokering 做到「不落地明碼密碼」,還無法像 SSH 一樣留下完整的畫面回放紀錄。
影響範圍:接 Vault 做 JIT 憑證發放
憑證的動態產生仰賴 Boundary 與 Vault 的整合,支援的 Vault 部署型態包括 HCP Vault Dedicated、Vault Enterprise,以及 IBM Vault Self-Managed for Z and LinuxOne——這是專門跑在大型主機作業系統上的 Vault 版本,讓 RACF passphrase 這類主機原生憑證也能走 just-in-time 發放與到期自動失效。Boundary 本身則有 HCP Boundary(代管控制平面)與 Boundary Enterprise(自管控制平面)兩種部署選擇。對長期只能靠共用帳號、跳板機、VPN 隔離主機網段的維運團隊來說,這套設計等於把 Zero Trust 的 session 代理與憑證輪替,第一次完整涵蓋到 z/OS 這類傳統上被排除在外的資產類型。
原始來源:Boundary Session Recording 文件、Boundary–Vault 整合文件、HashiCorp Blog 原文
HashiCorp Vault Agentic IAM 正式 GA:用 IETF RFC 9396 讓 AI Agent 的每次請求都只拿當下需要的權限
HashiCorp Developer Docs · 2026-09-01
HashiCorp 宣布 Vault Enterprise 的 Agentic IAM 能力正式 GA,官方文件標示此功能需要 Vault Enterprise 2.0.3 以上版本或對應的 HCP Vault Dedicated 叢集。這套機制的定位是把 AI agent 當成第三種身分類型,和既有的人類身分、傳統服務身分(NHI)分開治理,理由是過去把 agent 塞進服務帳號模型後,權限普遍「一次給到位、之後就不再變動」,和 agent 任務範圍會動態變化的特性不匹配。
背景:scope 不夠用,才需要 RAR
這裡引入的關鍵標準是 IETF RFC 9396(OAuth 2.0 Rich Authorization Requests,RAR)。傳統 OAuth 的 scope 參數只能表達「給我這個資源的讀取權」這種粗粒度授權,無法表達「只准對這一筆交易授權到 123.50 美元」這類細粒度條件。RAR 定義了 authorization_details 這個 JSON 陣列參數,讓每次請求都能挾帶結構化、可驗證的細粒度授權範圍,而不是重新設計一組更複雜的 scope 命名規則。
核心規格:Agent Registry 與三層權限交集
每個要存取 Vault 的 agent 必須先在 Agent Registry 完成註冊,並對應到唯一一個 Vault Identity entity。存取判斷採用三層權限交集模型:人類基準 ACL policy、Agent Registry 裡的 agent 上限 policy、token 內的 RAR claim 三者取交集才是最終有效權限。認證流程上,agent 向受信任的 IdP 取得帶 authorization_details claim 的 OAuth JWT 直接換 Vault token;產生的 token 只在該次請求的生命週期內存在,不落地保存。
委派場景(agent 代表某使用者操作)透過 OAuth 2.0 Token Exchange(RFC 8693)實作,同樣套用交集邏輯:使用者權限 ∩ agent policy ∩ authorization details。Terraform Vault Provider 新增了 vault_agent_registration 與 vault_oauth_resource_server_config_profile 兩個 resource,分別對應宣告式的 agent 註冊與 OAuth resource server 的 JWT 驗證設定:
resource "vault_agent_registration" "ci_bot" {
name = "ci-release-agent"
identity = vault_identity_entity.ci_bot.id
policies = ["agent-ceiling-ci"]
}
resource "vault_oauth_resource_server_config_profile" "idp" {
issuer = "https://idp.example.com"
rar_required = true
}目前官方驗證過的 IdP 包括:
- IBM Verify
- Auth0
- PingFederate
- Microsoft Entra
- Okta
影響範圍
Agent Registry 的每次註冊與認證請求都會寫進 Vault 的 audit device,委派情境下可同時歸責到使用者與代其操作的 agent,補上純服務帳號模式下查不出「哪個流程動的手」的稽核缺口。UI 端提供 agent 身分、認證活動、政策與 namespace 的集中檢視與調整,不必每次都走 API 或 Terraform。HashiCorp 同步釋出 IBM Verify 與 Auth0 整合教學,作為導入的起點。
原始來源:Vault AI Agent Support 官方文件、IETF RFC 9396、IETF RFC 8693、HashiCorp Blog 原文