企业官网建设流程全解析

Agent Substrate egress代理与SD Mint：Actor如何零信任安全访问互联网完整指南

【免费下载链接】substrateAgent Substrate: the core system项目地址: https://gitcode.com/GitHub_Trending/substrate7/substrate

在 Agent Substrate 这个面向 AI Agent 的大规模沙箱运行时中，egress 代理（出口流量代理）与 SD Mint 证书即时签发机制，是保证每个 Actor 安全访问互联网的两大核心防线。本文将用大白话讲清楚：Actor 的出站流量如何被透明拦截、如何凭证书证明身份、又如何通过 EgressPolicy 与 MITM 拦截精确控制"能访问什么"。

为什么 Actor 需要出口代理？

Agent Substrate 把大量"Actor"（如 AI Agent 应用）高密度地复用到少数物理 Pod 上，沙箱技术包括 gVisor 和 microVM。这些 Actor 绝大多数时间不可信：它们可能执行任意代码、可能携带恶意指令。如果让它们自由直连互联网，就意味着：

• 🔓无法审计：不知道 Actor 访问了谁、发了什么；
• 🎭身份冒充：外部服务无法知道请求来自哪个 Actor；
• 🚪策略失控：无法阻止 Actor 访问内网敏感地址或外泄数据。

因此 Substrate 定下了一条硬性契约：Actor 的所有出站流量（TCP/UDP 目的端口 53 的 DNS 除外）必须经过 egress 策略执行点（PEP）。详见 docs/network-egress.md。

流量如何被透明拦截：从沙箱到网关

整个过程对 Actor 完全透明，共四步：

1. 拦截：Worker Pod 内用 nftables 把 Actor 的 TCP 出站流量重定向到节点上的atunnel组件；
2. 加密隧道：atunnel与 egress 网关（atenet-egress）之间建立 mTLS 双向认证隧道，并发送一条 HTTP/1.1CONNECT请求，其中只携带"原始目的 IP:端口"；
3. 身份验证：网关验证atunnel出示的 Actor 专属客户端证书，并向 ATE API 确认该 Actor 真实存在且正在运行；
4. 策略裁决：按该 Actor 的EgressPolicy决定放行、拒绝或进一步处理，然后才把流量转发到真正的上游。

这套信任边界非常严格：网关绝不信任 Actor 自己声称的任何信息（比如 Actor 在请求头里写的 Host），只信任 Substrate 管控通道里携带的信息——证书和atunnel构造的 CONNECT 请求。

Actor 沙箱(不可信) → nftables 重定向 → atunnel(mTLS隧道) → atenet-egress(验身份+策略) → 授权的上游

用证书证明身份：ActorIdentity 扩展

Actor 激活时，atunnel会生成私钥并向 Substrate 申请一张短期客户端证书。这张证书：

• 由 Actor Identity CA 签发，包含 atespace、Actor 名称、UID；
• 携带一个专门的ActorIdentityX.509 扩展，标注用途为atunnel；
• 网关必须校验证书链、有效期，并向 ate-api-server 二次确认"这个 UID 对应的 Actor 此刻真实且正在运行"。

这意味着证书无法在 Actor 被删除重建后继续冒充它——UID 对不上就直接拒绝。持有普通 Pod 身份但没有 Actor 证书的客户端，连 TLS 握手都过不去。

EgressPolicy：默认拒绝的目的地白名单

即使身份合法，Actor 默认不能访问任何地方——没有策略就没有隧道。管理员可以为 Actor 配置EgressPolicy，规则按顺序匹配、首条命中生效，常见两类规则：

对于网关能直接读到的明文 HTTP 请求，策略是逐请求裁决；对于它解不开的加密流量，则在 CONNECT 建连时按地址裁决。策略缓存 TTL 默认 10 秒，删除策略后新请求立即变成拒绝。策略编译与求值逻辑见 internal/egresspolicy/egresspolicy.go。

SD Mint：如何连 HTTPS 也能逐请求检查？

普通网关面对 Actor 的 HTTPS 流量时只能看到加密字节，只能按地址放行。如果想对 HTTPS逐请求执行策略（比如检查 Host、未来注入凭证），就需要网关"看懂"内层明文——这就是SD Mint的作用。

SD Mint 是atenet内建的一个"即时签发证书的 SDS 服务"（源码见 cmd/atenet/internal/sdsmint/，包定义在 doc.go）：

1. 终止 TLS：sdsmint 安装下的 egress 网关终结 Actor 打开的每个 TLS 连接；
2. 按 SNI 即时制证：针对每次连接请求的域名（SNI），网关用自己的 MITM CA 现场签发一张短期叶证书（默认 TTL 15 分钟，核心实现见 minter.go）；
3. 重发起连接：网关验证该证书合法后，再以真实域名作为 SNI 向上游重新建立 TLS，并校验上游证书；
4. 逐请求裁决：解密后的明文进入egress_tls_mitm检查链，按 Host 对所有策略规则逐请求求值。

由于 Actor 看到的是网关签发的证书而非上游真证书，Actor 的信任配置必须指向网关 CA。Substrate 的做法是通过systemInfo卷把网关 CA（trustBundle: egress-mitm.ate.dev）投射到沙箱文件系统（如/run/ate/trust-bundle.pem），再配合SSL_CERT_FILE/SSL_CERT_DIR等环境变量让运行时只信任这张 CA。完整的配置指南在 docs/egress-trust-bundle.md，三种检查链（egress/egress_cleartext/egress_tls_mitm）的分工说明见 cmd/atenet/internal/router/README.md。

⚠️ 注意：sdsmint 是实验特性（安装时加--experimental-use-sdsmint，对应清单 manifests/ate-install/atenet-egress-with-sdsmint.yaml）。在非 sdsmint 环境配置信任包会直接让 Actor 起不来——因为没有任何东西会向它出示由网关 CA 签发的证书。

快速上手：跑通 egress 演示

仓库提供了一个端到端演示，展示"透明隧道 + 身份认证 + 策略放行"的完整闭环，支持 Envoy（默认）或 agentgateway 两种数据面。步骤概要：

1. 装系统：./hack/install-ate-kind.sh --deploy-ate-system（可选--atenet-dataplane=agentgateway）；
2. 部署演示：./hack/install-ate.sh --deploy-demo-egress，再kubectl ate create actor egress-demo -a ate-demo-egress --template egress；
3. 跑自动化测试：./demos/egress/test-egress.sh—— 它会验证"正例"（真实 Actor 经网关成功请求，目标服务看到的客户端 IP 正是网关）与"反例"（无 Actor 证书的 Pod 无法建立隧道）；
4. 观察日志：Envoy 的[egress]访问日志会记录 CONNECT 目标与已验证的 Actor 证书 SAN。

完整操作手册（含 MITM 变体 egress-mitm.yaml.tmpl）见 demos/egress/README.md。

小结：三层防线，一张信任链

三层叠加，构成"Actor 不可信、平台全托管"的零信任出口：Actor 只需像平时一样发起连接，安全裁决全部发生在它看不见的可信通道里。

延伸阅读

• 出口流量契约（传输、信任边界、服务端 TLS）：docs/network-egress.md
• MITM 信任包配置指南：docs/egress-trust-bundle.md
• 威胁模型与信任边界：docs/threat-model.md
• 术语表（Actor、atenet、atunnel 等）：docs/glossary.md
• 网关 egress 处理链源码：cmd/atenet/internal/router/README.md

【免费下载链接】substrateAgent Substrate: the core system项目地址: https://gitcode.com/GitHub_Trending/substrate7/substrate