Core Question

Agent workload 如何從執行環境取得可驗證身分，又不把 credential 烘進 image 或環境變數？

今天的問題

把客服 Agent 打包成 image，並用 AGENT_TOKEN 環境變數注入 production secret，看似方便，卻讓 image layer、debug dump、sidecar 與同 namespace process 都可能取得它。更麻煩的是，Kubernetes Pod 名稱或 IP 不是密碼學身分，重建 Pod 後名稱、位置和實際程式可能改變。

為什麼這不是傳統 IAM 問題

Agent 的 identity 應描述「此 workload 以哪個版本、哪個 instance 執行」，不是描述某個 container host。它還要與 User delegation、Task 和 Tool audience 分開。Container scheduler 可協助提供 runtime context，但不能因為 Pod 被排程就自動讓 Agent 讀所有 CRM。

Threat / Failure Scenario

Naive / Unsafe Design

Secret baked into image 或長效 Secret mount；任何同 image replica 都可呼叫所有 Tool，credential 不隨 Pod 撤銷。攻擊者取得 image 或環境 dump 後可離線重放。

Recommended Design

Runtime 透過受保護的 workload API/attestor 取得 SVID 或短效 token；issuer 根據 workload attributes（namespace、service account、image measurement 等）建立 stable workload ID 和 instance credential。Gateway 只信任 issuer 的簽章/信任 bundle，再對 Agent Action 作 authorization。

核心概念

Workload attestation 把「在哪裡執行」轉成可驗證的 Agent Identity，但不會自動授予業務權限；User delegation、Task 與逐 Action authorization 仍須分開判斷。

Architecture Pattern

Trust boundary 是 image/runtime、attestor/issuer、Gateway/PDP、Tool。SPIFFE Workload API 是平台無關的取得身分介面；其 SVID 由 trust domain 驗證，Workload API 也支援 X.509-SVID 與 JWT-SVID。SPIFFE 文件指出 X.509-SVID 通常較不易遭 token replay，且 identity/key 可短效輪替。Kubernetes、Docker 在此只是 mapping：前者可把 service account、namespace 和 workload selector 給 attestor；後者可用本機 Unix socket/受限 helper 模擬同一個 flow。

Identity Flow 完成後，spiffe://corp/agent/support 只證明 caller workload；sub=Alice、Task、資料範圍仍須由 delegation issuer 產生。Authorization Decision Point 在 Gateway/PDP，不能把 namespace label 當成 business permission。

小型 PoC

以下用標準庫模擬 image 沒有 secret，runtime 從本機 attestor 取得短效 identity；Kubernetes 實際 integration 不是本例驗證範圍。

import json, os, tempfile, time

def attest(env):
    # only attestor may see runtime attributes; image has no credential
    return {"workload": env["WORKLOAD"], "instance": env["INSTANCE"], "exp": int(time.time()) + 60}

with tempfile.TemporaryDirectory() as d:
    image = os.path.join(d, "image.json")
    with open(image, "w") as f: json.dump({"app": "support-agent"}, f)
    assert "token" not in json.load(open(image))
    identity = attest({"WORKLOAD": "spiffe://corp/agent/support", "INSTANCE": "pod-7"})
    assert identity["workload"].startswith("spiffe://corp/")
    assert identity["exp"] > int(time.time())
    print("image has no credential; runtime received short-lived workload identity")

實際驗證時應把 attest 換成受保護的 Workload API，驗證 issuer chain、trust bundle、audience、expiry 與 instance 狀態；不應把這個示意 JSON 當成 production credential。

證據至少包括 workload selector、image digest、instance identity、attestation reference、issuer、trust bundle version、credential expiry 與每次 Action 的 allow/deny。這讓調查者能區分「Pod 有身分」和「Pod 被允許執行這次 Action」。

今天得到什麼

1. Pod 名稱、IP 和 image 不是足夠的 Agent workload identity。
2. credential 應由可驗證的 runtime context 動態取得，不寫入 image。
3. SPIFFE-style SVID 提供跨 scheduler 的 identity abstraction；trust domain 決定誰可驗證。
4. workload authentication 完成後，仍需 subject、Task 與 Action authorization。

下一篇

最後一篇身分 Part 會把問題推向多 Agent：Agent A 如何相信 Agent B，而不是只相信 B 的名稱或能力宣告？

參考資料

• SPIFFE Standard
• SPIFFE Workload API
• SPIFFE Concepts：SVID 與 trust bundle
• Kubernetes Service Accounts 官方文件