Agent Substrate 网络出口（Network Egress）契约解析：atunnel mTLS CONNECT 隧道与策略执行点（PEP）的完整实现指南

人工智能AI AgentAgent 沙箱云原生容器运行时零信任【免费下载链接】substrateAgent Substrate: the core system项目地址https://gitcode.com/GitHub_Trending/substrate7/substrate点击查看免费下载导读本文是 Agent Substrate 中网络出口强制模型Network Egress Contract的深度技术指南。它定义了 Actor 的所有出站流量如何被强制经过出口策略执行点PEP详细说明了 atunnel 客户端与 PEP 之间基于 mTLS 的 HTTP/1.1 CONNECT 隧道协议、信任边界、服务端 TLS 证书体系、Actor 客户端证书的签发与校验以及逐请求per-request与逐连接per-connection的策略裁决模型。读完本文你将掌握出口数据面从 nftables 拦截到 CONNECT 隧道建立再到策略裁决的完整数据流、PEP 必须满足的合规要求证书、CA、扩展 OID、Actor 实时校验、以及如何在 Kubernetes 默认部署中依据 egress 策略 落地一套可验证、可排障的出口网关。1. 出口契约所有出站流量必须经过策略执行点Agent Substrate即本仓库所实现的核心系统对 Actor 的出站流量施加了强制的网络出口契约除了发往 TCP 或 UDP 53 号端口DNS的流量之外Actor 产生的所有出站流量都必须经过一个出口策略执行点Policy Enforcement PointPEP。这个 PEP 可以按需依据 substrate 原生的出口策略EgressPolicy对流量执行检查inspect、过滤filter或重定向redirect。本文档即是对 substrate 与出口 PEP 之间这一契约的正式说明。关键点在于DNS 豁免发往目标端口 53 的 TCP/UDP 流量被允许绕过 PEP用于 DNS 解析其余所有非 TCP/UDP 协议一律被阻止。其余流量全部经 PEP任何非 DNS 的 TCP 流量都必须经由 atunnel 打开隧道交给 PEP任何非 DNS 的 UDP 流量与所有其他协议流量一律由 nftables 过滤永远不会到达网关。这一策略在 docs/egress-traffic.md 中被细化为一张完整的支持矩阵是理解什么能出去、什么会被拒绝的行为基线详见第 6 节。2. 传输通道atunnel 与 mTLS HTTP/1.1 CONNECT 隧道2.1 谁是谁atunnel 与 PEP 的角色从组件角度看术语定义见 docs/glossary.mdateom是运行在每个 worker pod 内的协调器负责驱动沙箱运行时并内嵌了一个名为atunnel的网络服务为沙箱内的 Actor 处理网络流量atunnel是可信的隧道客户端trusted tunnel client运行在 worker pod / ateom 中负责为 Actor 打开出口隧道PEP如atenet-egress网关是 mTLS 监听端与 CONNECT 终结端负责认证、授权与转发。2.2 流量路径与 CONNECT 请求构造当前实现中Actor 的 TCP 流量按如下路径退出沙箱Actor 进程发起connect(IP:port)沙箱命名空间内的nftables 以 TCP REDIRECT截获该连接并通过SO_ORIGINAL_DST机制让 atunnel 获知连接本来的目标地址atunnel 作为可信隧道客户端将流量转发给 PEP。atunnel 在启动时被配置为 PEP 的网络地址和端口并据此建立一个到 PEP 的mTLS HTTP/1.1 CONNECT 隧道。关键细节CONNECT 请求的目标request target与Host头都被设置为 atunnel 从 Actor TCP 连接推导出的原始目标 IP 与端口格式为IP:portActor 网络目前仅支持 IPv4IPv4-only隧道建立后PEP 与 Actor 之间在 CONNECT 内部交换原始双向字节流raw bidirectional bytesPEP 可依据策略选择透传pass through、检查、重定向或中间人MITM。这一点在 internal/atunnel/client.go 中有直接实现DialContext先校验目标地址必须是合法的IP:port见validateDestination随后通过c.dialContext(ctx, tcp, c.gatewayAddress)连接网关、以tls.Client完成握手再构造http.Request{Method: http.MethodConnect, URL: url.URL{Host: destination}, Host: destination}写出 CONNECT 请求并读取响应——只有 2xx 才会把 TLS 连接包装成bufferedConn返回给上层做双向转发。req : http.Request{ Method: http.MethodConnect, URL: url.URL{Host: destination}, Host: destination, }2.3 隧道建立后的转发与生命周期internal/atunnel/egress.go 中的Egress组件负责长期承载这些隧道Activate以已获得的 Actor 证书 到期时间激活一次出口会话并后台启动证书续期renew证书续期调度在剩余生命周期的90%处进行renewAfter返回remaining - remaining/10失败时按退避策略重试retryAfter且对Aborted、FailedPrecondition、PermissionDenied等 gRPC 状态码不做重试而是直接阻断新出口连接证书过期只阻断新建隧道已用有效证书完成 mTLS 的既有隧道允许正常排空drainhandle中if time.Now().Compare(active.expiresAt) 0 { close }的分支与注释明确体现了这一只挡新的、不掐旧的语义每次收到被拦截的连接Egress通过originalDestination(conn)即SO_ORIGINAL_DST解析原始目标再调用dialer.DialContext(ctx, destination)打开隧道随后用copyBothWays在上下游之间做双向字节拷贝Deactivate用于在 Actor 迁移等场景下拒绝新出口、关闭活跃流并等待转发 goroutine 退出。3. 信任边界绝不信任来自 Actor 的任何声明Substrate 的信任模型非常明确所有源自 Actor 的信息都被视为不可信untrusted。因此出口 PEP绝不能信任 Actor 自身给出的任何决策或证明decision or attestation而必须只信任通过substrate 控制的通道携带的信息例如Actor 证书由 substrate 的 Actor Identity CA 签发经节点级 atelet 转发atunnel 产生的 CONNECT 请求目标地址来自内核SO_ORIGINAL_DST而非 Actor 自称的地址。由此导出一条重要约束PEP不得把 Actor 提供的 HTTP 主机名Hostname或 TLS SNI 当作原始目标就是该名字的证据。PEP 可以把主机名作为策略输入例如用于匹配 hostname 规则但当授权基于该主机名时PEP 必须把流量路由到被授权的主机名即按名字解析并拨号而不能反过来用主机名去授权一个来自 CONNECT 请求的任意 IP。从实现看internal/egresspolicy/egresspolicy.go 的Destination结构体正是这一模型的载体它区分Hostname请求所声明的规范化 DNS 名与IP将被拨号的地址并声明一条规则需要某个字段、而当前数据面环节无法提供该字段时该规则在此处永远不会匹配——这从代码层面保证了按名授权与按地址拨号不会混为一谈。Decision.ByName字段进一步标记命中的是 hostname 规则从而让数据面知道该请求必须按名字拨号详见 cmd/atenet/internal/router/egress/request.go 中dial : extproc.EgressDialAddress; if decision.ByName { dial extproc.EgressDialName }的选择逻辑。4. 服务端 TLSPEP 证书与默认 Kubernetes 部署的签发链路4.1 PEP 必须满足的服务端证书要求出口 PEP 必须使用满足以下条件的证书提供 TLS 服务证书对配置给 atunnel 的 PEP 主机名有效即 SAN 覆盖该主机名证书链到 atunnel 所信任的 CAatunnel 以配置的 PEP 主机名作为 TLS 服务端名称ServerName/SNI并在无法验证 PEP 证书时必须拒绝连接。这一要求在 internal/atunnel/client.go 的tls.Config中直接可见MinVersion: tls.VersionTLS12、RootCAs来自TrustBundlePath、ServerName: cfg.ServerName。此外NewClient在启动阶段就会对四项配置做硬性校验——GatewayAddress必须是合法的host:port、ServerName非空、必须提供GetClientCertificate回调、TrustBundlePath非空且其中必须包含至少一张证书——任一不满足都会直接报错避免带病启动。握手失败时返回ErrGatewayHandshake明确归类为网关正门front door在 TLS 层拒绝。4.2 默认 Kubernetes 部署servicedns 签名器与 projected 卷在默认 Kubernetes 部署中PEP 的证书与私钥通过projectedpodCertificate卷获得签名器为 substrate 的 Service DNS 签名器servicedns.podcert.ate.dev/identity。该签名器从选择该 PEP Pod 的 Service 中推导证书的 DNS SAN因此必须满足PEP必须被某个 Service 选中否则没有可推导的 SAN配置在 atunnel 里的主机名必须匹配其中一个 Service DNS 名默认 PEP 的名字是atenet-egress.ate-system.svc。卷内容分工如下credential-bundle.pem包含服务端证书链与私钥同一签名器的ClusterTrustBundle为 atunnel 提供对应的信任锚trust anchors。在 manifests/ate-install/atenet-egress.yaml 中可以看到这个 projected 卷的完整定义podCertificate源声明signerName: servicedns.podcert.ate.dev/identity、keyType: ECDSAP256、credentialBundlePath: credential-bundle.pem并搭配clusterTrustBundle源带podcert.ate.dev/canarying: live标签选择器输出trust-bundle.pem。Envoy 通过SDSsds-servicedns-cert.yaml监视/run/servicedns.podcert.ate.dev目录来获取旋转后的证书与私钥watched_directory只在 SDS 交付的 secret 上生效。同一份清单中的servicedns卷还同时被ext-proc 边车挂载使用它以--ateapi-ca-file/run/servicedns.podcert.ate.dev/trust-bundle.pem校验 ate-api-server 的服务端证书从而让 egress 网关通过受控通道与控制面建立信任。5. 客户端授权Actor 专属证书的签发、呈现与三重校验5.1 证书的签发私钥不出 atunnel短生命周期证书经 atelet 获取atunnel 在连接 PEP 时必须出示Actor 专属的客户端证书。签发流程如下Actor 激活时atunnel 生成一把私钥当前为 ECDSA P-256见 internal/atunnel/credential.go 的ecdsa.GenerateKey(elliptic.P256(), rand.Reader)atunnel 通过节点本地 atelet请求一张短生命周期short-lived证书私钥始终留在 atunnel 内只有 CSR 跨过 atelet 的凭证代理 Unix socketBrokerCertificateSource的MintAteomCertificate即此逻辑每次 mint 都新建 gRPC 连接以强制校验 atelet 当前的证书与节点身份证书标识 Actor 的 atespace、名称name与 UID并被限定scoped到atunnel这一用途purpose。atunnel 侧在安装证书时会做一轮防御性校验internal/atunnel/credential.go证书公钥必须与私钥匹配、生命周期必须合法、必须携带ClientAuth扩展用途、必须含且仅含一个有效的ActorIdentity扩展、用途必须是atunnel、且扩展中的 Actor UID 必须与当前激活的 Actor 一致。GetClientCertificate回调则在握手时拒绝使用已过期的证书。5.2 PEP 侧的强制校验链PEP必须在接受任何 CONNECT 请求之前要求并验证客户端证书校验项包括证书链与有效期必须链到 Actor Identity CA且处于有效期内客户端认证用途必须包含ClientAuthclient authentication usage扩展用途恰有一个有效的ActorIdentity扩展其中 atespace、Actor 名称、Actor UID 与 purpose 必须齐全当前扩展 OID 为1.3.6.1.4.1.11129.2.12.2分配在 Google 的企业号Private Enterprise NumberPEN下CNCF 捐赠完成后将会变更该扩展的 purpose必须是atunnel证书的 actor URI SAN 必须标识与扩展相同的 Actor实时向 ate-api-server 确认Actor 仍然存在、其当前 UID 与证书一致、且处于运行running状态。上述任何一项检查失败PEP 都必须拒绝该 CONNECT 请求。5.3 源码级证据OID、扩展解析与防重放OID 定义internal/substratex509/substratex509.goGoogleSubstratePEN asn1.ObjectIdentifier{1, 3, 6, 1, 4, 1, 11129, 2, 12} oidActorIdentity makeSubstrateOID(2) // 1.3.6.1.4.1.11129.2.12.2扩展以JSON而非 ASN.1编码ActorIdentity携带Atespace / ActorName / ActorUid / Purpose四个字段validateActorIdentity强制四个字段非空且Purpose atunnelinternal/substratex509/substratex509.go。这也解释了为什么该 OID 会随 CNCF 捐赠而变更它目前挂在 Google 的 PEN 弧1.3.6.1.4.1.11129之下。PEP 的 Go 侧重校验cmd/atenet/internal/router/egress/egress.goverifyActorCertificate尽管 Envoy 已在握手层以trusted_ca校验过链Go 侧仍重新验证整条链——理由是该处理器反正要解析证书读取 Envoy 无法读取的自定义扩展而信任一个已解析但未验证的证书是经典的 CVE 来源这也使得即使 Envoy 配置将来被放宽处理器仍然安全拒绝IsCA证书防止泄露的 CA 证书被当作叶子证书重放显式要求ClientAuth扩展用途slices.Contains(leaf.ExtKeyUsage, x509.ExtKeyUsageClientAuth)因为 crypto/x509 中空 ExtKeyUsage 意味着任意用途必须显式校验通过ActorIdentityFromCertificate解析扩展要求恰好一个、内容合法且 purpose 为atunnel校验 URI SAN 恰好一个且等于该 Actor 的 SPIFFE IDresources.ActorSPIFFEID(...)确保扩展与 SAN 指向同一 Actor。Actor 实时状态校验validateActorcmd/atenet/internal/router/egress/egress.go通过 ateapi 的GetActor查询控制面要求 Actor 存在、UID 匹配以 UID 授权而非名字防止证书签发给 A、名字被 B 复用、且状态为ACTOR_STATE_RUNNING。控制面不可用Unavailable/DeadlineExceeded时返回 503失败关闭fail closed而不是放行。5.4 身份在数据面内部的传播不经过任何 Actor 可写的头PEP 内部Envoy 网关场景的身份传播也严格遵循信任边界CONNECT 外层的 ext_proc 决策结果把 Actor 身份写入filter statedev.ate.actor.identity取自 Envoy 校验过的对端证书 URI SAN内层逐请求裁决直接读取该 filter state绝不读取任何请求头——因为隧道内部的一切字节都是 Actor 可控的。这一点在 cmd/atenet/internal/router/egress/egress.go 的包注释与 cmd/atenet/internal/router/egress/request.go 的actorFromFilterState中均有明确体现。6. 出口流量支持矩阵什么能出去被拒时 Actor 看到什么结合 docs/egress-traffic.mdPEP 行为的具体支持矩阵如下这是契约在流量分类上的落地TCP端口流量行为路径被拒时 Actor 所见anyHTTP(S) 1.1 / 2支持受策略控制atunnel → egress 网关 → 源站403 ForbiddenanyWebSocket阻止n/a403 Forbiddenany标准 HTTP(S) CONNECT正向代理隧道阻止n/a403 Forbidden53DNS经 netfilter 规则放行nftables → 节点配置的 DNSn/aany任何其他 TCP阻止n/a连接被接受后立即关闭不返回任何字节无状态码atunnel 记录失败日志UDP端口流量行为路径被拒时 Actor 所见53DNS经 netfilter 规则放行nftables → 节点配置的 DNSn/a其他任何其他 UDP阻止n/a丢包而非拒绝不发送 ICMP port-unreachable客户端将一直挂起直到自身超时其他协议一切既非 TCP 也非 UDP 的流量均被阻止。同样采取丢包而非拒绝策略不发送 ICMP port-unreachable客户端挂起至自身超时。注DNS-over-TCP、UDP 及其他流量由 nftables 过滤永远不会到达网关见 docs/egress-traffic.md。如果你需要上述被阻止的出口流量类型获得支持可以向仓库提交描述用例的 issue。在 Envoy 网关实现中WebSocket 的阻止效果来自 manifests/ate-install/atenet-egress.yaml 的配置注释若不显式配置upgrade_configsEnvoy 会自己应答 Upgrade 请求导致握手失败而清单中的 inner listener 显式允许了 websocket upgrade——但注意egress_cleartext链的每个请求仍要经过 ext_proc 的策略裁决未获授权即返回403。而连接被接受后关闭的语义则由egress_tcp_passthrough/egress_passthrough链体现没有original_dst_addressfilter state 时连接在转发任何字节之前就被关闭日志中flags UH。7. 策略裁决模型CONNECT 决地址、请求决名字PEP 对隧道内流量的授权是分层的由 cmd/atenet/internal/router/egress 中的 ext_proc 处理器实现7.1 策略本体EgressPolicy 与三种规则每个 Actor 最多有一个名为default的EgressPolicy资源嵌套于 Actor 之下见 pkg/proto/ateapipb/ateapi.proto其rules按顺序求值第一条匹配的规则授权该请求、仅应用该规则的效果effects、求值即停止即使后面的规则也会匹配没有任何规则匹配则拒绝。每种规则使用恰好一种目标匹配器pkg/proto/ateapipb/ateapi.protoHostnameRulehostnames按目标主机名匹配。pattern 为小写、无尾点的 DNS 名或左起标签带*.的通配符——*.example.com匹配恰好一个非空左标签如api.example.com不匹配example.com与nested.api.example.com不支持其他通配符语法。国际化域名须用 IDNA A-labelpunycode形式。可携带effects见下CIDRRulecidrs按原始目标 IP是否属于某个前缀匹配。必须是规范形式的 IPv4 点分十进制或 IPv6 小写压缩形式前缀长度之后的位必须为零AllRuleall匹配一切目标。每条规则最多 256 项maxItems256规则整体最多 256 条规则顺序是有意义的listTypeatomic不能被打乱。EgressRuleEffects仅由 hostname 规则携带且不授权流量只在规则匹配时生效当前支持inject_static_headers——从凭证提供方credential provider取回的值注入请求头如Authorization: Bearer token前缀由配置给出。凭证 URI 使用ate-secret://scheme由 cmd/atenet/internal/router/egress/provider.go 的DialProvider以 mTLS 拨号凭证提供方开发环境可用--credential-provider-insecure显式关闭 TLS但生产禁止。7.2 匹配语义解析后的Destination与Evaluateinternal/egresspolicy/egresspolicy.go 是纯函数式的策略求值包无 I/O、无日志且与 ate-api-server 共用同一套解析器保证校验与匹配永不漂移Compile一次性解析所有 pattern 与 CIDR无法解析的条目被丢弃并上报fail closed只会收窄 allow 规则策略始终可用Evaluate顺序遍历规则返回第一条匹配的Decision含Allowed、RuleIndex、hostname 规则的Effects与ByName标记NormalizeAuthority把:authority/Host值规范化为Destination拆出端口、IP 字面量转netip.Addr、DNS 名小写化并去掉一个尾点、校验为 DNS-1123 子域名——IP 字面量不产生 hostname、最后一段全数字的名字被拒绝防止01.2.3.4这类被解析器接受的点分十进制伪装成域名任何异常一律拒绝通配符*.example.com只替换完整的最左标签Matches中label ! !strings.Contains(label, .)。7.3 三个数据面环节的决策分工以 Envoy 网关atenet-egress为例流量依次经过以下裁决环节与文末的 CONNECT 路径图对应CONNECT 环节外层链egresscmd/atenet/internal/router/egress/egress.gohandleConnect认证 Actor 证书 → 校验身份 → 向 ate-api-server 确认 Actor 实时状态 → 以NormalizeAuthority(md.Host)解析 CONNECT authority必须为 IP:port出现主机名即拒绝→ 用**地址规则cidrs / all**裁决目标地址。三种结局地址规则允许 → 隧道打开目标地址作为动态元数据dev.ate.egress:passthrough_destination传给透传链拨号无地址规则允许但策略含 hostname 规则 → 隧道打开但无可拨号地址只有随后被名字规则允许的请求才能通过两者皆无 → 在此处拒绝 CONNECT此时还有响应通道返回403。逐请求环节内层egress_cleartext/egress_tls_passthrough等链cmd/atenet/internal/router/egress/request.gohandleRequest从 filter state 取 Actor 身份绝不信请求头→ 用请求的:authority/Host名字与 CONNECT 记录的原拨号地址地址组合成Destination→ 顺序求值首条匹配规则决定放行与去向hostname 规则命中 →dial name按名字动态解析egress_forward_proxy_cleartext集群dns_lookup_family: ALL支持 Happy Eyeballs并拨号地址/all 规则命中 →dial address拨号到 Actor 原始拨号地址egress_original_dst_cleartext/egress_tcp_passthrough均为ORIGINAL_DST集群未命中 →403。若:authority与Host指向不同目标直接拒绝而非按一个名字授权、按另一个名字拨号。透传环节egress_tls_passthrough/egress_passthroughPEP 不终结的 TLS 及其余无法分类的字节流仅当 CONNECT 环节由地址规则允许并设置了original_dst_addressfilter state 时才拨号无此状态即关闭连接。7.4 策略缓存的失效关闭语义lookupPolicycmd/atenet/internal/router/egress/egress.go对四种情况做了区分调用方取消 → 400/超时Actor 无策略 → 403控制面故障 →503fail closed不缓存策略存在但规则数为零 → 403没有规则即什么都不能授权。policyCacheTTL为 0 时每个 callout 都实时拉取策略。8. 一张图看懂完整出口数据流下图原文档所附的权威路径图展示了当前 CONNECT 出口路径——每个 Actor TCP 连接一个隧道除目标端口 53 外CURRENT CONNECT EGRESS PATH (one tunnel per actor TCP connection except destination port 53) Actor sandbox Worker pod / ateom Egress PEP Authorized upstream ------------------ -------------------------- ------------------------- ------------------ | Actor process | | nftables | | mTLS listener | | Target selected | | (untrusted) | | TCP REDIRECT | | CONNECT terminator | | under policy | ----------------- ------------------------- ------------------------ ----------------- | connect(IP:port) | | | --------------------------------| | | | SO_ORIGINAL_DST | | v | | ------------------------- | | | atunnel | | | | (trusted tunnel client) | | | ------------------------- | | | | | | TLS 1.2 mutual authentication | | | actor-specific client certificate | | ----------------------------------| verify certificate and | | | authorize current actor | | | | | HTTP/1.1 CONNECT IP:port | | | Host: IP:port | | ----------------------------------| validate destination; | | | evaluate egress policy | | | | | HTTP/1.1 2xx | | |---------------------------------- | | | CIDR/all policy: | | | dial now; | | | hostname policy: | | | inspect inner request | | | before dialing | | -------------------------| | | | | raw bidirectional bytes inside CONNECT || | (PEP may pass through, inspect, redirect, or MITM according to policy) |9. 工程落地要点与排障速查9.1 部署 PEP 时的强制清单MUST 项PEP 必须为配置给 atunnel 的主机名提供有效证书并链到 atunnel 信任的 CA默认部署走servicedns.podcert.ate.dev/identity签名器见 manifests/ate-install/atenet-egress.yamlPEP 必须被 Service 选中且 atunnel 配置的主机名须匹配该 Service 的 DNS 名默认atenet-egress.ate-system.svcPEP 必须要求并验证 Actor 客户端证书链到 Actor Identity CA、ClientAuth用途、恰一个ActorIdentity扩展OID1.3.6.1.4.1.11129.2.12.2purpose 为atunnel、URI SAN 与扩展一致PEP 必须实时向 ate-api-server 确认 Actor 存在、UID 匹配、状态为 running控制面故障时失败关闭503授权基于主机名时必须按名字拨号绝不用名字授权任意 IP。9.2 常见故障与日志线索TLS 握手失败ErrGatewayHandshake客户端证书被拒或 PEP 证书未通过验证。gatewayHungUp会区分对端 TLS alertnet.OpError的 Op 为remote error与对端直接断开/重置EOF、EPIPE、ECONNRESET两类原因CONNECT 被拒ConnectRejectedError携带状态码如 403与消息此时客户端已认证成功但被授权拒绝策略被拒egress denieddeniedBody具体原因只进服务端日志、不回给 Actor未认证成功者不配获得细节网关无 actor-identity CAactorIdentityRoots nil所有 CONNECT 以503失败关闭——这是网关自身配置问题不是 Actor 的问题。对应 manifests/ate-install/atenet-egress.yaml 中--actor-identity-ca-file/run/actor-id-ca-certs/ca.crt的注释没有这个 flag路由器就没有 actor-identity roots会以 503 拒绝每一个出口 CONNECTnftables 放行/拦截不符预期检查端口 53 豁免与SO_ORIGINAL_DST是否生效因为非 TCP/UDP 与 DNS-over-TCP 之外的流量根本不会到达网关out-of-date Actor / 续期被拒Aborted/FailedPrecondition/PermissionDenied等 gRPC 码不会重试续期被拒后新出口连接被阻断atunnel日志有明确警告透传链无目标可拨日志flags UH说明 CONNECT 环节没有地址规则放行且内层请求也没有被允许——连接在转发前被关闭。9.3 观察与遥测atenet-egress的 Envoy 在每个环节都输出结构化访问日志manifests/ate-install/atenet-egress.yaml外层 CONNECT 日志[egress] authority%REQ(:AUTHORITY)% peer_san%DOWNSTREAM_PEER_URI_SAN% peer_serial%DOWNSTREAM_PEER_SERIAL% passthrough%DYNAMIC_METADATA(dev.ate.egress:passthrough_destination)% code%RESPONSE_CODE% ...内层 cleartext 日志JSON 格式含actorfilter state 中的身份、authority、method、status、upstream等字段passthrough 日志含sni仅记录、不做决策依据与destinationfilter state 中的原始目标地址。10. 小结Agent Substrate 的网络出口契约把所有出站流量必须经过 PEP这一强制策略落实为一条清晰的信任链内核 nftables 拦截 →SO_ORIGINAL_DST还原真实目标 → atunnel 以 Actor 专属短生命周期证书发起 mTLS CONNECT → PEP 验证证书与 Actor 实时状态 → 按 EgressPolicy 分层裁决CONNECT 决地址、逐请求决名字→ 依据命中规则按名或按地址拨号。整条链路的每一步都不信任 Actor 的声明身份只来自 substrate 控制的证书通道任何失败都以关闭fail closed收场。这套契约的权威定义即 docs/network-egress.md其数据面行为基线见 docs/egress-traffic.md完整参考实现可进一步阅读 internal/atunnel、internal/egresspolicy、internal/substratex509 与 cmd/atenet/internal/router/egress以及 manifests/ate-install/atenet-egress.yaml 中的部署清单。赞分享人工智能AI AgentAgent 沙箱云原生容器运行时零信任【免费下载链接】substrateAgent Substrate: the core system项目地址https://gitcode.com/GitHub_Trending/substrate7/substrate点击查看免费下载相关推荐Agent Substrate 可插拔 Egress 组网实战基于 mTLS HTTP CONNECT 的 Actor 出站隧道全解析Agent Substrate 可插拔 Egress 组网实战基于 mTLS HTTP CONNECT 的 Actor 出站隧道全解析 导读 本文围绕 A人工智能AI AgentAgent 沙箱云原生容器运行时零信任Agent Substrate 出站流量Egress Traffic支持矩阵与 atunnel 隧道原理Agent Substrate 出站流量Egress Traffic支持矩阵与 atunnel 隧道原理 导读 本文围绕 docs/egress traff人工智能AI AgentAgent 沙箱云原生容器运行时零信任Swift Package Manager 中 CXXLanguageStandard 的不等运算符!解析用法、实现与底层原理Swift Package Manager 中 CXXLanguageStandard 的不等运算符!解析用法、实现与底层原理 导读 本文围绕 Swif开发工具构建工具上一篇Score Specification安全扫描集成发现配置漏洞下一篇brave/browser-laptop性能分析报告瓶颈识别与优化建议创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考