2026-09-09 — Docker Sandboxes 的 MicroVM 隔離、Kubernetes OIDC Public Client 存取與 GitHub Actions 免侵入式追蹤

Docker 推出 Sandboxes：以硬體層 MicroVM 隔離取代容器邊界，圈住 AI Coding Agent 的執行風險

docker.com · 2026-09-08

Docker 於 2026 年 9 月 8 日發布部落格文章，說明新產品 Docker Sandboxes 如何用硬體層隔離取代傳統容器邊界，讓 Claude Code、Gemini CLI、Copilot CLI、Codex、Kiro、OpenCode 等 AI coding agent 在不觸碰開發者本機憑證與檔案系統的前提下自主執行程式碼。文章引用 Docker 自家《State of Agentic AI》調查，指出六成組織已把 AI agent 用於正式環境作業。

背景：自主 agent 與開發者憑證共用同一台機器

傳統做法是讓 coding agent 直接在開發者筆電上安裝套件、跑腳本、呼叫外部服務，與人類共用同一組 SSH 金鑰、雲端憑證與網路存取權限。這種共用執行環境的模式代表一旦 agent 被提示注入（prompt injection）誤導或裝進惡意套件，取得的權限與可信身分和開發者本人幾乎沒有差別。Docker 把問題定義成「犯錯發生時爆炸半徑有多大」，而非單純的「agent 會不會犯錯」。

核心改動：MicroVM 取代容器，憑證只在邊界注入

Docker Sandboxes 的隔離手段是把每個 sandbox 放進獨立的 microVM，而不是沿用容器共用 host kernel 的模式；每個 sandbox 擁有自己的 Linux kernel，形成 hypervisor 等級的邊界，而不只是容器層級的命名空間隔離。依 Docker 架構文件，每個 sandbox 也維護自己的 Docker daemon 狀態、image cache 與套件安裝結果，彼此不共用 image 或 layer；對外 TCP 流量統一經由 host 端 proxy 轉送，HTTP/HTTPS 走 forward proxy、其餘 TCP 採 transparent forwarding。掛載的工作目錄預設啟用 virtiofs 快取，官方文件也提到操作用的 CLI 工具 sbx（目前版本 0.42.0）新增了可選的 workspace path 參數。

憑證處理是這次架構設計的核心賣點：密鑰不會以環境變數或掛載檔案的形式出現在 sandbox 內部，而是存放在 host 端的 keychain，只在對外請求送出的那一刻於網路邊界注入。sandbox 內的 workload 拿到的是「請求已附帶憑證」的效果，卻從未真正持有密鑰本體，這阻絕了外洩、被記錄、或被提示注入誘導洩漏的路徑。policy 可控制的範圍包含：

• 網路存取：限制可連線的網域與 IP 範圍
• 檔案系統：限制可存取的 host 路徑，讓 SSH 金鑰、雲端憑證等敏感路徑不可觸及
• 憑證：由 host keychain 管理，僅在邊界注入，不落地於 sandbox 內
• 生命週期：sandbox 可快速建立與丟棄，丟棄後所有套件、程序、系統變更一併清除，只保留掛載的工作目錄

影響範圍：治理延伸到組織層級，三種角色各自受益

Docker 同時將這套隔離模型延伸為獨立產品 Docker AI Governance，把單一 sandbox 的網路、檔案系統、工具存取規則放大成組織層級的集中政策，並提供跨開發機器的稽核紀錄。文章把六項效益整理成不同角色的關注點：

文章特別強調 sandbox 內仍是完整的 Linux 開發環境，而非閹割過的沙盒：內建完整 Docker daemon，agent 可以在裡面建置與執行容器、跑測試套件、安裝服務與資料庫，同時完全隔絕於 host 的 Docker daemon 之外，避免因為環境功能不足而被迫把工作丟回 host 執行。

原始來源：Docker Blog、Docker Sandboxes Architecture Docs

Kubernetes 存取控制：CNCF 部落格主張以 OAuth Public Client 取代長效憑證與共用密鑰

cncf.io · 2026-09-08

CNCF 部落格於 2026 年 9 月 8 日刊出 Kolawole Olowoporoku（CNCF Ambassador）的文章，主張自架 Kubernetes 叢集串接身分提供者時，kube-apiserver 的 OIDC 用戶端應設定為 OAuth 定義下的 public client 並搭配 PKCE，而非傳統的 confidential client 加共用密鑰。這是作者整理的叢集「day-zero」存取控制檢查清單的一環。

背景：自架叢集預設沒有身分治理，只有靜態憑證

自行架設的 Kubernetes 叢集不像受管服務那樣內建身分整合，預設只能靠靜態的用戶端憑證或長效 token做叢集存取，這類憑證通常一次核發後就很少被重新檢視。人員異動、職務調整或裝置遺失之後，要撤銷存取權必須找出憑證散落在哪些機器上的每一份拷貝，而這件事在實務上很少被徹底執行完畢。

核心改動：Public Client + PKCE 取代共用密鑰

文章指出 confidential client 模式需要一把 client secret 分發給每一台要存取叢集的機器，但「必須分發給每個用戶端的密鑰，已經不是密鑰，只是多了幾道手續的共用靜態憑證」。改用 public client 完全不核發 client secret，而是靠 PKCE（Proof Key for Code Exchange）機制：用戶端在本機產生一個亂數值，先送出其雜湊值當作登入請求的一部分，等到用授權碼交換 token 時再證明自己持有原始亂數值，藉此防止授權碼被攔截後遭冒用交換 token。

整體架構由三個元件組成：kubectl 搭配 kubelogin 的 oidc-login exec plugin 發起登入並向 IdP 換取 ID token；身分提供者（文章以 Keycloak 示範）驗證使用者並在 ID token 中帶入使用者名稱與群組宣告；kube-apiserver 驗證 token 簽章、抽取身分宣告後交給 RBAC 做授權判斷。

設定細節：kube-apiserver 與 Keycloak 端

--oidc-issuer-url=https://<keycloak-host>/realms/<realm>
--oidc-client-id=kubernetes
--oidc-username-claim=preferred_username
--oidc-groups-claim=groups
--oidc-ca-file=/etc/kubernetes/pki/oidc-ca.crt

文章特別提醒 --oidc-ca-file 對自簽憑證環境是必要設定，少了它 OIDC 驗證會直接因 TLS 驗證失敗而整組壞掉。Keycloak 端則要把用戶端類型設為 public、關閉 client authentication、開啟 standard flow 並強制 S256 方式的 PKCE，redirect URI 限制在 http://127.0.0.1:* 與 http://localhost:* 這類 loopback 位址，並在 realm 層加上一個把群組寫進 groups claim 的 protocol mapper。

影響範圍：稽核粒度與撤銷流程的轉變

kubeconfig 端不需要任何 secret 欄位：

users:
  - name: oidc
    user:
      exec:
        apiVersion: client.authentication.k8s.io/v1
        command: kubectl
        args:
          - oidc-login
          - get-token
          - --oidc-issuer-url=https://<keycloak-host>/realms/<realm>
          - --oidc-client-id=kubernetes

導入後，稽核記錄的主體從「同一把共用憑證做的所有動作」變成可歸屬到個別使用者的身分，RBAC 授權也改用群組層級的 ClusterRoleBinding 綁定 IdP 群組，而非逐一綁定憑證主體；撤銷存取權從「在整個基礎設施裡找憑證拷貝並刪除」變成單純的身分系統操作。文章建議用 kubectl auth whoami 驗證目前登入身分與群組是否正確對應。

原始來源：CNCF Blog

免修改 GitHub Actions 工作流程：OpenTelemetry 的 GitHub Receiver 如何把 CI 事件轉成分散式追蹤

cncf.io · 2026-09-08

CNCF 部落格於 2026 年 9 月 8 日刊出 George Sims（downtherabbithole.dev）的文章，說明如何透過 OpenTelemetry Collector Contrib 專案中仍屬 alpha 階段的 GitHub receiver，在完全不更動任何 GitHub Actions workflow 檔案的前提下，把 CI 執行事件轉換成 OTLP 格式的分散式追蹤資料。文章以 CNCF 已畢業專案 Kubernetes 的 CI 規模為案例背景，凸顯 GitHub Actions 用量成長速度已經超前既有的可觀測性佈署。

背景：規模化之後失去的 CI 可視性

當一個組織的 workflow 數量與 repository 數量同步膨脹，在每個 workflow 內埋 tracing SDK 的做法會變得不可規模化——每個 repo 都要改 workflow 檔案，語法調整還得在所有 repo 同步更新。文章鎖定的正是這個維運痛點：如何在不碰觸既有 workflow YAML 的情況下，取得跨組織的 CI 執行時間、排隊延遲與失敗率視覺化。

核心改動：org 層級 Webhook 直接餵給 Collector

做法是在 GitHub organization 層級註冊一個 webhook，監聽 workflow_run 與 workflow_job 事件，直接送到一個公開可達、跑著 OpenTelemetry Collector GitHub receiver 的 endpoint；不想管理共用 webhook secret 的團隊，也可以改用 GitHub App 方式接收同樣事件。receiver 收到事件後把資料轉成三層 span 結構：workflow 對應最外層 span，job 是子 span，job 底下每個 step 再變成孫 span，span／trace ID 全部由 run_id、run_attempt、check_run_id 與 step 名稱雜湊決定性產生——這代表同一個 job 裡的 step 名稱必須唯一，否則雜湊會互相碰撞。

receivers:
  github:
    webhook:
      endpoint: 0.0.0.0:19418
      path: /events
      secret: ${env:GITHUB_WEBHOOK_SECRET}
    scrapers:
      scraper:
        github_org: ${env:GITHUB_ORG}

exporters:
  otlp:
    endpoint: ${env:TRACE_BACKEND_ENDPOINT}
    headers:
      authorization: ${env:TRACE_BACKEND_API_KEY}

service:
  pipelines:
    traces:
      receivers: [github]
      exporters: [otlp]

兩種收集模式的差異

輸出格式一律是 vendor-agnostic 的 OTLP，因此下游可以接 Tempo、Jaeger、Datadog 等任何相容後端，不會被單一追蹤系統綁定。

影響範圍：資料涵蓋面與已知限制

導入後可取得的資料包含 workflow 執行時間與狀態、job 排隊與執行時間、單一 step 耗時、flakiness 指標，以及跨組織的 CI 健康度統計。但認證與資料完整性上有明確限制：若 PAT 對某些 repository 沒有存取權，只能拿到 repository 數量這類最基本的 metric；自建立以來未曾有 commit 的分支不會產生 metric；GitHub API 本身的限制也會讓分支時間戳記 metric 在 rebase 後發生位移。receiver 的 changelog 顯示語意慣例經歷過屬性改名，從更早版本升級到 v1.37.0 時把 organization.name 改名為 vcs.owner.name、vcs.vendor.name 改名為 vcs.provider.name，目前 receiver 遵循的是 OpenTelemetry Semantic Conventions v1.40.0。部署上還需要一個公開可達的 Collector endpoint，並針對 GitHub webhook 來源網段做 IP allowlist 或 WAF 防護。

原始來源：CNCF Blog、OpenTelemetry Collector Contrib – githubreceiver