1. 項目緣起當AI智能體涌入Kubernetes我們?nèi)绷耸裁醋罱肽晡宜诘膱F隊一直在探索如何將各類AI智能體Agent安全、高效地部署到Kubernetes集群中。從簡單的任務(wù)調(diào)度器到復(fù)雜的多步推理工作流我們嘗試了各種框架和模式。但很快一個比“如何運行”更根本的問題浮出水面在一個動態(tài)、多租戶的K8s環(huán)境里我們?nèi)绾沃馈罢l”在運行如何信任它以及當我們需要調(diào)用某個特定能力的智能體時又該如何精準地找到它這聽起來像是服務(wù)發(fā)現(xiàn)Service Discovery和身份認證Identity的老問題但AI智能體帶來了全新的挑戰(zhàn)。傳統(tǒng)的K8s Service通過標簽Label選擇器來暴露一組Pod其核心假設(shè)是后端實例是相對靜態(tài)、功能同質(zhì)的。而AI智能體往往是有狀態(tài)的、能力異構(gòu)的、生命周期多變的。一個負責代碼審查的Agent和一個負責日志分析的Agent雖然都是Pod但它們的“身份”遠不止一個IP地址或服務(wù)名那么簡單。這個身份需要包含其能力描述、所屬項目、版本、甚至其訓(xùn)練數(shù)據(jù)的哈?；蚰Ｐ椭讣y以便調(diào)用方能夠驗證其可信度。更棘手的是治理Governance。當成百上千個由不同團隊、甚至不同供應(yīng)商開發(fā)的AI智能體在集群中共存時如何審計它們的調(diào)用鏈如何實施基于能力的訪問控制比如只有經(jīng)過安全審計的“金融數(shù)據(jù)查詢Agent”才能訪問生產(chǎn)數(shù)據(jù)庫如何確保一個聲稱是“最新版翻譯Agent”的Pod沒有被惡意替換或篡改現(xiàn)有的K8s原生資源如Service、ConfigMap、乃至新興的ServiceEntryIstio都無法完整地承載這些元數(shù)據(jù)和安全訴求。我們需要的不是一個簡單的服務(wù)注冊中心而是一個面向AI智能體的、可驗證的信任層。這就是我們啟動“Agent Name Service”ANS概念驗證項目的核心動機。它不是一個要替代現(xiàn)有系統(tǒng)的龐然大物而是一個輕量的、增量的信任層旨在為Kubernetes中的AI智能體生態(tài)補上最關(guān)鍵的一塊拼圖。2. ANS核心架構(gòu)一個基于聲明式身份的信任三角ANS的設(shè)計哲學(xué)非常明確輕量、聲明式、可驗證。我們不希望引入一個中心化的、沉重的控制平面而是充分利用Kubernetes已有的擴展能力和聲明式API的理念。整個系統(tǒng)的核心圍繞著三個關(guān)鍵概念構(gòu)建我稱之為“信任三角”身份聲明Identity Claim、信任錨點Trust Anchor和發(fā)現(xiàn)端點Discovery Endpoint。2.1 身份聲明從Pod到“可信智能體”在K8s里一個Pod最基本的身份是它的名稱和命名空間。但這對于智能體來說遠遠不夠。ANS引入了一個新的自定義資源定義CRDAgentIdentity。apiVersion: ans.acme.corp/v1alpha1 kind: AgentIdentity metadata: name: code-review-agent-v1 namespace: platform-team spec: # 核心身份描述 agentRef: kind: Deployment name: code-review-agent namespace: platform-team capabilities: - name: code_review version: 1.2.0 description: Static analysis and security vulnerability detection for Python/Go code. inputSchema: {...} # OpenAPI Schema 片段 outputSchema: {...} # 可驗證的憑證 verifiableCredentials: - type: ModelIntegrity issuer: internal-model-registry.acme.corp claim: sha256:abc123... # 容器鏡像中模型文件的哈希 proof: jwt:eyJ... # 由簽發(fā)者簽名的JWT - type: SecurityAudit issuer: security-team.acme.corp claim: passed_penetration_test_v2 validUntil: 2024-12-31T23:59:59Z # 治理元數(shù)據(jù) owner: platform-engineeringacme.corp project: devsecops-automation lifecycleStage: production這個AgentIdentity資源就是智能體的“身份證”。它不直接控制Pod的創(chuàng)建而是通過agentRef關(guān)聯(lián)到實際的工作負載Deployment、StatefulSet等。capabilities字段是關(guān)鍵它用結(jié)構(gòu)化的方式描述了智能體能做什么這比K8s Label的鍵值對更豐富、更機器可讀。verifiableCredentials是信任的基石它允許外部權(quán)威機構(gòu)如內(nèi)部模型倉庫、安全團隊為智能體的特定屬性如模型完整性、安全審計狀態(tài)背書并生成密碼學(xué)證明。為什么選擇CRD而不是Annotation我們最初考慮過用Pod Annotation來存儲這些信息。但CRD提供了更強的類型安全、獨立的生命周期管理智能體身份可以在Pod重建后依然存在、以及更便捷的查詢能力通過K8s API。更重要的是它符合K8s的“資源即狀態(tài)”哲學(xué)。2.2 信任錨點如何建立和傳遞信任有了身份聲明接下來要解決“誰說了算”的問題。在零信任架構(gòu)中我們不能默認信任集群內(nèi)的任何實體。ANS的信任模型基于公鑰基礎(chǔ)設(shè)施PKI的簡化變體。根信任錨Root Trust Anchor在集群初始化時由集群管理員部署一個包含公鑰的ConfigMap或者更佳實踐是使用K8s的CertificateSigningRequest(CSR) API關(guān)聯(lián)一個外部證書頒發(fā)機構(gòu)CA。這個錨點對所有AgentIdentity中verifiableCredentials的簽發(fā)者issuer進行認證。憑證簽發(fā)者Credential Issuers像“內(nèi)部模型倉庫”、“安全團隊”這些實體它們需要向根信任錨證明自己的身份并獲得簽發(fā)特定類型憑證的權(quán)限。在PoC中我們通過為這些服務(wù)配置特定的ServiceAccount并綁定相應(yīng)的RBAC角色來實現(xiàn)其行為記錄可通過K8s審計日志追蹤。憑證驗證鏈當一個服務(wù)消費者需要調(diào)用某個智能體時它從ANS發(fā)現(xiàn)端點獲取到目標AgentIdentity。消費者并不需要完全理解所有憑證它只需要驗證兩點第一憑證的簽發(fā)者issuer是否在它信任的列表中這個列表可以來自根信任錨第二憑證的簽名proof是否有效。這個過程可以在消費者端離線完成無需每次都查詢中心化的授權(quán)服務(wù)。這個設(shè)計的巧妙之處在于解耦。安全團隊只負責簽發(fā)“安全審計通過”的憑證模型倉庫只負責簽發(fā)“模型哈希一致”的憑證。智能體的所有者負責將這些憑證收集起來聲明在自己的AgentIdentity中。而智能體的消費者則可以根據(jù)自己的安全策略決定需要哪些憑證才能建立信任例如“對于處理PII數(shù)據(jù)的智能體必須同時具備‘安全審計’和‘數(shù)據(jù)加密認證’兩張憑證”。2.3 發(fā)現(xiàn)端點超越Kubernetes Service的智能查找傳統(tǒng)的服務(wù)發(fā)現(xiàn)kubectl get svc或DNS查詢返回的是IP和端口。ANS的發(fā)現(xiàn)端點一個簡單的HTTP/gRPC服務(wù)返回的是富語義的智能體身份信息。發(fā)現(xiàn)端點提供兩種主要查詢模式精確發(fā)現(xiàn)通過唯一的AgentIdentity名稱進行查詢。這適用于已知確切身份的調(diào)用場景。能力發(fā)現(xiàn)這是更強大的功能。消費者可以提交一個“能力需求清單”進行查詢。{ requiredCapabilities: [ {name: sentiment_analysis, minVersion: 2.0.0}, {name: chinese_language} ], requiredCredentials: [ {type: ModelIntegrity, issuer: trusted-model-hub}, {type: DataPrivacy, level: gdpr_compliant} ] }發(fā)現(xiàn)端點會掃描所有AgentIdentity找出同時滿足能力要求和憑證要求的智能體并返回它們的訪問端點通常是關(guān)聯(lián)的K8s Service地址和完整的身份信息。這個發(fā)現(xiàn)端點本身是無狀態(tài)的它通過監(jiān)聽K8s API Server實時索引集群內(nèi)所有的AgentIdentity資源。它的高可用可以通過簡單的Deployment多副本來實現(xiàn)。為了性能我們可以在內(nèi)存中維護一個索引按能力和憑證類型進行倒排使得即使面對上千個智能體查詢也能在毫秒級返回。3. 在Kubernetes中的集成與實踐從概念到運行設(shè)計理念再美好也需要落地。接下來我將詳細拆解如何將一個現(xiàn)有的AI智能體工作負載接入ANS體系并展示一個完整的互操作流程。3.1 準備工作部署ANS控制平面組件ANS的控制平面非常精簡主要由三部分組成ANS Operator這是一個標準的K8s Operator負責管理AgentIdentityCRD并確保其狀態(tài)與關(guān)聯(lián)的工作負載一致例如當對應(yīng)的Deployment被刪除時清理孤立的AgentIdentity。使用Operator Framework如Kubebuilder開發(fā)部署為一個Deployment。發(fā)現(xiàn)端點服務(wù)Discovery Endpoint Service如前所述一個提供查詢API的服務(wù)。我們選擇用Go編寫利用client-go庫監(jiān)聽AgentIdentity資源的變化。它通過ClusterIP Service暴露。信任錨點配置我們選擇使用K8s的ValidatingWebhookConfiguration和自簽證書作為一個輕量級的起點。為簡化PoC我們預(yù)先將受信任的簽發(fā)者公鑰以ConfigMap形式掛載到發(fā)現(xiàn)端點和關(guān)鍵消費者Pod中。部署清單大致如下# 1. 安裝CRD kubectl apply -f deploy/crd/agentidentity.yaml # 2. 部署ANS Operator和RBAC配置 kubectl apply -f deploy/operator.yaml # 3. 部署發(fā)現(xiàn)端點 kubectl apply -f deploy/discovery-service.yaml # 4. 配置信任錨示例將一個已知公鑰存入ConfigMap kubectl create configmap ans-trust-anchors --from-filepublic-key.pem./keys/trusted-issuer.pub3.2 為你的AI智能體申領(lǐng)“身份證”假設(shè)我們有一個已部署的“代碼安全掃描智能體”其Deployment名為code-scanner。接入ANS分為三步第一步由智能體所有者創(chuàng)建AgentIdentity。# code-scanner-identity.yaml apiVersion: ans.acme.corp/v1alpha1 kind: AgentIdentity metadata: name: prod-code-scanner namespace: ai-agents spec: agentRef: kind: Deployment name: code-scanner namespace: ai-agents capabilities: - name: static_analysis version: 3.1.0 description: Detects security vulnerabilities (SQLi, XSS, etc.) in Java and Python code. inputSchema: type: object properties: repositoryUrl: type: string branch: type: string required: [repositoryUrl] verifiableCredentials: # 假設(shè)我們已經(jīng)從內(nèi)部安全掃描服務(wù)獲取了一個簽名的JWT憑證 - type: SecurityScan issuer: internal-security-scanner.svc.cluster.local claim: severity_critical_zero proof: eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9... # 實際的JWT令牌 owner: appsec-teamacme.corp應(yīng)用這個YAML文件kubectl apply -f code-scanner-identity.yaml。ANS Operator會驗證agentRef引用的Deployment是否存在并將該AgentIdentity標記為Bound狀態(tài)。第二步獲取可驗證的憑證關(guān)鍵步驟。這是建立信任的核心。在我們的PoC中我們模擬了一個“內(nèi)部安全掃描服務(wù)”。該服務(wù)有一個獨立的Pod其ServiceAccount被授權(quán)使用特定的簽名密鑰。智能體部署后流水線可以調(diào)用這個掃描服務(wù)的API對智能體的容器鏡像進行掃描。掃描通過后該服務(wù)會簽發(fā)一個包含掃描結(jié)果如severity_critical_zero并附有數(shù)字簽名的JWT令牌。這個令牌就是verifiableCredentials中的proof。第三步更新Service以供發(fā)現(xiàn)。這步是可選的但建議操作。為了能讓發(fā)現(xiàn)端點將AgentIdentity解析為可訪問的網(wǎng)絡(luò)端點最佳實踐是確保智能體工作負載有一個同名的K8s Service。ANS發(fā)現(xiàn)端點會默認嘗試查找agentRef.name這個Service。如果Service名稱不同可以在AgentIdentity的status字段或通過注解來指定。3.3 消費者如何發(fā)現(xiàn)并調(diào)用一個可信智能體現(xiàn)在另一個團隊想要在CI流水線中集成代碼安全掃描。他們不需要知道智能體具體部署在哪里只需要找到一個可信的、具備該能力的智能體。第一步查詢發(fā)現(xiàn)端點。消費者Pod或外部服務(wù)可以向集群內(nèi)的發(fā)現(xiàn)端點發(fā)起查詢# 通過能力查找 curl -X POST http://ans-discovery.ai-system.svc.cluster.local/discover \ -H Content-Type: application/json \ -d { requiredCapabilities: [{name: static_analysis, minVersion: 3.0.0}], requiredCredentials: [{type: SecurityScan}] }第二步處理發(fā)現(xiàn)結(jié)果。發(fā)現(xiàn)端點會返回一個JSON數(shù)組包含匹配的智能體身份和訪問信息[ { identity: { name: prod-code-scanner, namespace: ai-agents, capabilities: [...], verifiableCredentials: [...] }, endpoint: http://code-scanner.ai-agents.svc.cluster.local:8080, verified: true // 表示發(fā)現(xiàn)端點已初步驗證憑證簽名 } ]注意發(fā)現(xiàn)端點返回的verified: true僅代表它驗證了憑證的簽名有效性。消費者必須根據(jù)自身的安全策略對憑證的具體聲明claim進行二次校驗。例如安全策略可能要求SecurityScan憑證的claim必須是最近7天內(nèi)簽發(fā)的。第三步執(zhí)行調(diào)用與驗證。消費者可以選擇verified為true且評分最高的智能體未來可以加入健康狀態(tài)、負載等指標。在發(fā)起實際業(yè)務(wù)請求前一個嚴謹?shù)南M者應(yīng)該從返回的verifiableCredentials中提取出JWT令牌proof。使用本地配置的、來自信任錨點的公鑰驗證JWT的簽名確保憑證未被篡改。檢查JWT中的聲明如issuer,claim,exp是否符合自己的策略要求。只有全部驗證通過消費者才向endpoint發(fā)起業(yè)務(wù)請求。這個過程雖然增加了少量開銷但實現(xiàn)了去中心化的、基于密碼學(xué)的信任驗證避免了將所有信任決策依賴于一個中心化的網(wǎng)關(guān)。4. 深入治理策略引擎與可觀測性增強ANS提供的身份層為更高級別的治理奠定了數(shù)據(jù)基礎(chǔ)。在PoC中我們探索了兩個關(guān)鍵的治理擴展動態(tài)策略執(zhí)行和增強的可觀測性。4.1 基于OPA/Gatekeeper的策略執(zhí)行開放策略代理OPA和它的K8s原生項目Gatekeeper是定義和執(zhí)行集群策略的事實標準。結(jié)合ANS的AgentIdentity我們可以實現(xiàn)精細化的治理規(guī)則。例如我們可以定義一個Gatekeeper約束模板Constraint Template禁止任何沒有有效“數(shù)據(jù)隱私憑證”的智能體被掛載含有敏感數(shù)據(jù)的卷# 約束模板require-data-credential-for-sensitive-volume apiVersion: templates.gatekeeper.io/v1beta1 kind: ConstraintTemplate metadata: name: requiredatacredentialforsensitivevolume spec: crd: spec: names: kind: RequireDataCredentialForSensitiveVolume targets: - target: admission.k8s.gatekeeper.sh rego: | package requiredatacredentialforsensitivevolume violation[{msg: msg}] { # 1. 檢查Pod是否掛載了標記為敏感的卷 input.review.object.kind Pod volume : input.review.object.spec.volumes[_] volume.secret ! null volume.secret.secretName prod-database-credentials # 示例敏感密鑰 # 2. 查找Pod對應(yīng)的AgentIdentity通過標簽或所有者引用 identity : data.inventory.namespace[namespace][“agentidentities.ans.acme.corp/v1alpha1”][name] # 3. 檢查Identity中是否包含所需的憑證 not cred : identity.spec.verifiableCredentials[_] cred.type DataPrivacy cred.issuer compliance-team.acme.corp # 4. 如果不滿足則生成違規(guī)信息 msg : sprintf(Pod %v uses sensitive volume but its AgentIdentity lacks required DataPrivacy credential, [input.review.object.metadata.name]) }然后創(chuàng)建一個約束實例apiVersion: constraints.gatekeeper.io/v1beta1 kind: RequireDataCredentialForSensitiveVolume metadata: name: require-data-cred-for-db-secret spec: match: namespaces: [ai-agents]當有人嘗試部署一個掛載了prod-database-credentialsSecret但未關(guān)聯(lián)合規(guī)AgentIdentity的Pod時Gatekeeper會在準入階段直接拒絕該請求。這實現(xiàn)了“基于身份的治理”策略的觸發(fā)條件從簡單的資源屬性升級到了智能體可驗證的信用屬性。4.2 可觀測性在鏈路追蹤中注入身份信息在微服務(wù)架構(gòu)中分布式追蹤如Jaeger、Zipkin通過TraceID將一次請求的多個服務(wù)調(diào)用串聯(lián)起來。對于AI智能體調(diào)用鏈我們同樣需要這種可見性并且希望看到更豐富的身份信息。ANS可以與OpenTelemetry這樣的可觀測性框架集成。在每個智能體的Pod中注入一個OpenTelemetry Sidecar或直接在應(yīng)用代碼中集成SDK。在創(chuàng)建Span代表一個工作單元時除了常規(guī)的標簽還可以將AgentIdentity中的關(guān)鍵信息添加進去例如agent.identity.name:prod-code-scanneragent.capability:static_analysis3.1.0agent.credential.security_scan:passed這樣在追蹤UI中查看一個CI流水線的調(diào)用鏈時你不僅能看到它調(diào)用了service-a和service-b還能清晰地看到它調(diào)用了**“具備安全掃描憑證的生產(chǎn)環(huán)境代碼掃描智能體v3.1.0”**。當出現(xiàn)問題時例如掃描結(jié)果異常你可以快速定位到具體是哪個版本的哪個智能體并查驗其憑證狀態(tài)極大提升了排查效率。這個集成的價值在于將運維數(shù)據(jù)追蹤、日志與安全/信任數(shù)據(jù)身份、憑證關(guān)聯(lián)了起來為故障診斷、合規(guī)審計和安全事件調(diào)查提供了統(tǒng)一的上下文。5. 概念驗證的挑戰(zhàn)、取舍與未來演進在構(gòu)建這個PoC的過程中我們遇到了不少預(yù)料之中和預(yù)料之外的挑戰(zhàn)也做出了一些關(guān)鍵取舍。挑戰(zhàn)一憑證的生命周期管理。verifiableCredentials中的JWT令牌會有過期時間。如何自動輪換我們的方案是引入一個“憑證續(xù)訂器”Credential Renewer作為DaemonSet運行。它監(jiān)視所有AgentIdentity在憑證過期前調(diào)用相應(yīng)的憑證簽發(fā)者服務(wù)申請新的令牌并更新AgentIdentity資源。這要求簽發(fā)者服務(wù)提供續(xù)訂API并且更新操作需要被RBAC嚴格控制。挑戰(zhàn)二性能與規(guī)模。發(fā)現(xiàn)端點的內(nèi)存索引在智能體數(shù)量極大數(shù)萬時可能成為瓶頸。下一步演進方向是引入分片索引或使用外部鍵值存儲如etcd的直接前綴查詢。此外消費者端的JWT驗證雖輕量但在超高頻調(diào)用場景下可以考慮使用短期緩存的驗證結(jié)果。挑戰(zhàn)三跨集群與混合云場景。PoC聚焦于單個K8s集群。但在現(xiàn)實中智能體可能分布在多個集群、甚至云廠商之間。ANS的架構(gòu)可以擴展每個集群部署自己的ANS實例管理本集群的AgentIdentity。然后通過一個全局的、更上層的“聯(lián)邦發(fā)現(xiàn)服務(wù)”來聚合各集群的目錄。信任錨點也需要升級可能需要一個全局的、多集群認可的根CA體系。關(guān)鍵取舍深度集成 vs. 外部系統(tǒng)。我們曾討論是否直接使用SPIFFE/SPIRE作為身份基礎(chǔ)。SPIFFE提供了強大的、標準化的身份框架。但考慮到AI智能體身份信息的豐富性能力描述、治理元數(shù)據(jù)和我們需要深度集成K8s資源模型最終決定基于CRD自建一層。ANS可以看作是SPIFFE在AI智能體領(lǐng)域的一個“特化實現(xiàn)”未來完全有可能將AgentIdentity的verifiableCredentials與SPIFFE Verifiable Identity Document (SVID) 進行映射或融合。未來演進方向標準化能力描述capabilities字段的Schema可以嘗試對齊諸如MLflow Model Registry、OpenAI Function Calling等生態(tài)的標準促進互操作性。智能體市場與調(diào)度結(jié)合能力發(fā)現(xiàn)可以構(gòu)建一個集群內(nèi)的“智能體市場”。更高級的調(diào)度器可以根據(jù)任務(wù)需求“需要圖像識別和中文NLP”自動選擇并調(diào)度滿足條件且可信的智能體實例。策略即代碼的深化將更多的治理邏輯如訪問控制、資源配額、成本歸屬與AgentIdentity綁定實現(xiàn)真正的“身份驅(qū)動治理”。這個ANS的PoC項目讓我們深刻認識到在云原生AI時代身份是新的邊界。Kubernetes提供了卓越的“計算調(diào)度層”而我們需要一個與之匹配的“智能體信任層”來管理其中的主體。ANS的探索只是一個開始它的核心價值在于提出了一種基于聲明式、可驗證身份的治理范式這或許能為未來多智能體系統(tǒng)的安全協(xié)作打下第一塊基石。