English Abstract: This post wraps up the three-part Docker × AI Agent series. Each article added one defensive layer for containers that run autonomous AI agents: kernel isolation with MicroVM sandboxes, network and credential isolation with an internal-only Docker network and an egress proxy, and resource circuit breaking with cgroups and ulimit. It summarizes the three layers side by side and traces how each one builds on earlier Autocruise posts on Docker proxy configuration, Docker engine ulimits, and Docker credential stores. 近期連續三篇 Docker × AI Agent 系列文，應對的是同一個課題：當容器裡執行的不再是行為固定的微服務，而是會自行產生程式碼、呼叫 Shell 的 AI Agent，「在容器就安全」這個假設要怎麼修正。三篇文章各自補上一道防線，構築成防禦縱深，本文把它們整理在一起，作為此系列的索引。 （一）在 Docker 容器中執行 AI Agent，需要哪三道防線？ 在 Docker 容器中執行 AI Agent，需要同時具備 Kernel 隔離、網路與憑證隔離、資源熔斷三道防線，分別對應 Agent 突破隔離、帶走機密與耗盡資源三種風險。 防線 處理的風險 關鍵設定 Kernel 隔離 共用宿主機 Kernel、runc 漏洞、掛載 docker.sock sbx MicroVM、K8s RuntimeClass 網路與憑證隔離 /proc/self/environ、DNS 隧道、.env 外洩 internal: true 、Egress Prox...

English Abstract: Putting real API keys into the environment variables of AI agent containers is unsafe. An agent that can run shell commands can read them from /proc/self/environ, leak them through DNS queries, or expose them through a .env file. This article builds a zero-trust egress layer: an internal-only Docker network with no external route, plus an egress proxy that holds the real keys and swaps a phantom token for them only on allowlisted domains. It includes a runnable Docker Compose and mitmproxy setup, and extends the design into an enterprise AI gateway for key rotation, budget circuit breaking, and audit logging. 本文重點大綱 架構觀念翻轉 ：在微服務時代，The Twelve-Factor App 提倡將設定與憑證存入環境變數（Environment Variables）；但在具備 Shell 執行權限與自主控制迴圈（Control Loop）的 AI Agent 時代，將真實 API Key 放進容器環境變數等同於將機密公開。 三大真實攻擊向量與 CVE 佐證 ：深入剖析失控或遭受間接提示詞注入（Indirect Prompt Injection）的 AI Agent，如何繞過指令黑名單，透過 Linux /proc/self/environ 跨行程繼承 、 DNS 隧道（DNS Exfiltration，以 CVE-2025-55284 為例） 與 .env 渲染漏洞 竊取憑證。 視覺化網路拓撲與時序拆解 ...

English Abstract: Running an autonomous AI agent with --dangerously-skip-permissions inside a standard docker run container is not a security sandbox. Every runc-based container shares the host Linux kernel, so a runtime flaw such as runc CVE-2025-52881, a mounted docker.sock , or API keys passed in with -e can turn one misbehaving agent loop into a host-level incident. This post contrasts standard containers with MicroVM sandboxes, walks through a Docker Sandboxes ( sbx ) setup with a separate guest kernel, deny-by-default egress policy and host-side credential proxying, shows how to verify each isolation layer, and closes with a two-phase governance model that moves agentic workloads in Kubernetes onto Kata Containers or gVisor through RuntimeClass. 傳統容器 vs. MicroVM 沙盒：在 AI Agent 時代，重新定義容器隔離與 Proxy 憑證防護 本文重點大綱 傳統 Container 與 MicroVM Sandbox 的本質差異 ：從 Linux Kernel 共用與否，切開「確定性微服務」與「非確定性 AI Agent」的執行邊界。 實務風險拆解：從 runC 漏洞（CVE-2025-52881）到環境變數外洩 ：分析為何 --dangerously-skip-p...

無意中看到整合 AI Agent 的 PaaS 平台爆發資安事件：攻擊者從一把雲端管理憑證出發,一路打穿到主資料庫,把所有租戶存在環境變數裡的第三方金鑰整批查出來、匯出去。問題的根源不是「被駭」這件事本身,而是架構設計把太多信任集中在同一個地方，環境變數欄位是整個平台唯一的機密儲存層,一次控制平面層級的入侵,就足以讓所有租戶的金鑰在同一時間曝險。由此有一些想法，寫了這篇技術文章探討金鑰該如何儲存。 (一) 從攻擊鏈看金鑰為什麼能走這麼遠 該平台官方在事故發生後陸續更新的攻擊鏈,是這起事件最值得拆解的部分:攻擊者取得一把 AWS 管理層級的憑證,先進入東京的一個共用叢集,再從叢集摸到控制平面的 VPN,最後連上主資料庫,把使用者存在環境變數裡的金鑰查出來、匯出去。時間軸上,平台在 8 月 28 日凌晨建立事故頁,一開始只說是「內部服務憑證」被用來查詢環境變數紀錄;直到隔天晚間,才更新出「AWS 管理憑證 → 共用叢集 → 控制平面 VPN → 主資料庫」這條完整路徑。 如果那把 AWS 憑證的有效權限,本身就同時涵蓋叢集存取、VPN 素材、資料庫連線——那麼圖面上的四個箭頭,實際上可能從頭到尾只被同一個身分牽著走,中間沒有一關是「前一個身分拿不到、簽不出、也改不掉」的獨立授權。 要驗證一組雲端身分的真實影響範圍,不能只看掛了哪些 policy 名稱,而要直接查它的 effective permissions: aws accessanalyzer list-findings \ --analyzer-arn <analyzer-arn> \ --filter '{"resource":{"contains":["<role-or-user-arn>"]}}' 這個指令會列出該身分實際可觸及的資源, 找出哪些資源被過度開放給外部身分, 而不是政策文件上「看起來」授權了什麼——這正是重建這類事故攻擊面時,第一件該做的事。 (二) 問題不在用環境變數,而在把它當成信任根 環境變數本身不是問題。幾乎所有 PaaS——Heroku、Render、Vercel 等——都用環境變數當作應用程式讀取設定的方式,這是產業慣例,沒有問題。真正的問...

Dockerfile 看似簡單，幾行 FROM、RUN、COPY 就能把應用打包成 image，但寫得好不好，直接牽動 build 速度、image 大小、安全性與日後的可維護性。本文整理幾個實務中最常用、卻也最常被忽略的 Dockerfile 撰寫訣竅。 （一）善用 layer cache　，　指令由　變動較少　排到　容易變化　（由上到下） Docker build 是逐層（layer）快取的,只要某一層的指令或內容改變,該層之後的所有 layer 都會失效重建。因此在Dockerfile內容中，指令順序（由上到下）應該從「變動頻率低」排到「變動頻率高」。最典型的例子，是先複製相依清單、安裝套件，最後才複製原始碼： # 先處理相依,讓 cache 命中率最大化 COPY package.json package-lock.json ./ RUN npm ci COPY . . 如此一來,只要原始碼變動、相依沒變, npm ci 這一層就能命中 cache,不必重跑。 （二）用 multi-stage build 縮小 image 把「編譯環境」與「執行環境」分開，只把最終產物帶進 runtime image，可大幅縮小體積，也降低受攻擊面（attack surface）: FROM golang:1.22 AS builder WORKDIR /app COPY . . RUN go build -o server . FROM alpine:3.20 COPY --from=builder /app/server /server ENTRYPOINT ["/server"] runtime image 不再包含 compiler 與原始碼,從數百 MB 降到數十 MB 是常態。 （三）合併 RUN 並在同一層清理 cache 每一個 RUN 都是一層。把相關指令用 && 串接成一層,並在同一層清掉套件快取,避免多餘體積殘留在 image 裡: RUN apk add --no-cache curl \ && rm -rf /var/cache/apk/* Debian/Ubuntu 則常見 apt-get install 之後接 rm -rf /var/l...

導讀摘要： 面對數位轉型，許多企業往往陷入「專案式思維」的陷阱，導致 DevSecOps 轉型後，維運與資安成本不減反增。本文深度解析如何借鑑 Google SRE 核心邏輯，引進「安全性誤差預算」與「消除瑣事」機制。我們將探討如何透過自動化合規與平台工程，將安全從「昂貴的支出中心」轉化為「驅動業務的穩定引擎」。如果您正苦於雲端帳單失控或人肉維運的困境，這篇文章將為您提供量化管理維運成本的全新視角。 (本文含聯盟連結。As an Amazon Associate I earn from qualifying purchases.)

Recent media coverage in Taiwan has drawn attention to an administrative dispute involving a large-scale personal data exposure. Public reporting indicates that a significant number of household registration records were allegedly compromised, prompting at least one individual to seek a change to their national identification number as a precautionary measure. The request was reportedly declined, with authorities emphasizing administrative stability and systemic considerations. This article does not assess the legal merits of that case. Instead, it offers a general, technical reflection on why identity-related remedies can be operationally complex in large, legacy public systems. Identity Numbers as System Anchors In many government architectures worldwide, a national identification number functions as a foundational reference point rather than a simple attribute. From a systems design perspective, it often serves as a shared identifier across healthcare, taxation, social insur...