Kubernetes v1.36：細粒度 Kubelet API 授權正式 GA
Kubernetes Blog · 2026-04-24
Kubernetes v1.36 將 KubeletFineGrainedAuthz Feature Gate 鎖定為啟用，細粒度 Kubelet API 授權進入 General Availability。此功能自 v1.32 以 alpha 引入，v1.33 升至 beta（預設開啟），v1.36 GA 後 Feature Gate 不可再關閉。
舊有架構的安全風險
舊版設計中，kubelet HTTPS 端點的所有路徑（包含 pod 列表、節點指標、容器日誌、容器指令執行）都對應到同一個粗粒度的 nodes/proxy subresource。RBAC 若允許 nodes/proxy 的 GET 操作，等同允許存取所有 kubelet 路徑，包括 /exec。安全研究人員於 2026 年初示範，僅憑 nodes/proxy GET 權限即可透過 WebSocket 協定（RFC 6455 要求用 HTTP GET 進行握手）在容器中執行任意指令：
websocat --insecure \
--header "Authorization: Bearer $TOKEN" \
--protocol v4.channel.k8s.io \
"wss://$NODE_IP:10250/exec/default/nginx/nginx?output=1&error=1&command=id"
# Result: uid=0(root) gid=0(root) groups=0(root)新的 API 路徑對應
kubelet 現在將特定路徑映射至獨立的 subresource：
| Kubelet API 路徑 | Resource | Subresource |
|---|---|---|
| /stats/* | nodes | stats |
| /metrics/* | nodes | metrics |
| /logs/* | nodes | log |
| /pods, /runningPods/ | nodes | pods, proxy |
| /healthz, /configz | nodes | healthz/configz, proxy |
| 其他 | nodes | proxy（後備） |
雙重授權檢查與向後相容
對於有細粒度 subresource 的端點，kubelet 先以具體 subresource 發送 SubjectAccessReview；若失敗，再以 nodes/proxy 重試（向後相容）。這表示現有持有 nodes/proxy 權限的工作負載繼續正常運作。
最小權限設定範例
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: monitoring-agent
rules:
- apiGroups: [""]
resources: ["nodes/metrics", "nodes/stats"]
verbs: ["get"]上述設定僅允許讀取指標與統計，無法執行容器指令。舊版若使用 nodes/proxy，則需重新審視並縮小授權範圍。
原始來源：Fine-Grained Kubelet Authorization GA — Kubernetes Blog、KEP-2862、nodes/proxy RCE 研究
Kubernetes Gateway API v1.5：六項功能升至 Standard 頻道
Kubernetes Blog · 2026-04-21
Gateway API v1.5 於 2026-02-27 發布（目前已有 v1.5.1 修補版），是迄今最大幅度的版本，將六個 Experimental 功能同步晉升至 Standard（GA）頻道，並引入 Release Train 發布模型。
晉升至 Standard 的功能
- ListenerSet（GEP-1713）：允許在 Gateway 外部獨立定義 listener 並附加，解決多租戶場景中每個 Gateway 最多 64 個 listener 的限制。Gateway 本體的
listeners欄位仍需至少一個有效 listener。 - TLSRoute（GEP-2643）：以 SNI（Server Name Indication）進行路由比對，支援 Passthrough 模式（端到端加密，Gateway 不接觸私鑰）與 Terminate 模式（Gateway 終止 TLS）。注意：現有 Experimental TLSRoutes（v1alpha2/v1alpha3）與 v1.5 Standard 不相容，需手動遷移至
v1。 - HTTPRoute CORS Filter：直接在 HTTPRoute 上設定 CORS policy。
- Client Certificate Validation：TLS 連線的客戶端憑證驗證。
- Certificate Selection for TLS Origination：Gateway 向後端發起 TLS 時的憑證選擇控制。
- ReferenceGrant：跨命名空間引用授權機制。
Release Train 模型
自 v1.5 起，Gateway API 採用 Release Train 模型：功能（包含文件）須在 feature freeze 前完成，同時適用於 Experimental 與 Standard 頻道，確保更可預期的發布節奏。
原始來源：Gateway API v1.5 — Kubernetes Blog、GEP-1713、GEP-2643
KICS Docker Hub 供應鏈攻擊事件：憑證竊取覆蓋映像標籤的分層偵測機制
Docker Blog · 2026-04-23
2026-04-22 UTC 12:35，Docker Hub 上的 checkmarx/kics repository 遭受供應鏈攻擊。攻擊者使用竊取的 Checkmarx 發布者憑證，覆蓋現有的 5 個 tag 並新增 2 個惡意 tag。KICS 是廣泛用於掃描 Terraform、CloudFormation 和 Kubernetes 設定的 IaC 安全工具，受影響映像會在繼續提供合法掃描介面的同時，靜默地向攻擊者基礎設施外洩掃描到的 secrets 與雲端資源拓撲資訊。
攻擊技術細節
攻擊手法屬憑證式 registry 入侵：無需零日漏洞，僅憑竊取的發布者憑證即可透過正常發布流程推送惡意映像。惡意 payload 採雙層設計：外層維持合法 KICS 掃描功能以規避即時偵測，內層以 KICS-Telemetry/2.0 User-Agent 將加密後的掃描結果傳送至 audit.checkmarx[.]cx。
受影響映像的 IOC
Alpine/v2.1.20–21：sha256:2588a4489026...；Debian/v2.1.20-debian–21-debian：sha256:222e6bfed0f3...；latest：sha256:a0d9366f6f01...（完整 digest 詳見 Docker Security 公告）。
偵測機制：多層信號關聯
此次攻擊從推送到下架約 30 分鐘，關鍵在於三個信號的相互佐證：新 tag 出現但上游無對應發布、映像 provenance 指向建立僅一天的來源 repository、發布時間模式與正常行為不符。Docker 強調「任何單一信號無法抓到全部攻擊」，實際防禦依賴跨 Docker、Socket、Checkmarx、GitHub 的即時信號共享。
緩解措施
以 digest 固定映像版本（非 tag）；輪換曾在受影響環境中執行的所有憑證；檢查 egress 日誌中是否有 audit.checkmarx[.]cx 連線；清除本地快取、CI runner 快取與 pull-through registry 快取（普通重新拉取不足以移除已快取的惡意版本）。
原始來源：Trivy, KICS and Supply Chain Attacks — Docker Blog、Socket Technical Analysis