AI Agent 赋予机器自主执行能力，也打开了数据泄露与凭证滥用的潘多拉魔盒。CubeSandbox 以 KVM MicroVM 隔离为基座、eBPF 内核态网络为骨架、L7 代理深度检查为护盾，构建了一套从虚拟交换到应用层审计的端到端网络安全体系。本文逐层拆解 CubeVS、CubeProxy、CubeEgress 等核心组件的设计与实现，揭示其如何在开放执行与安全可控之间取得平衡。

◆1. 业务背景与需求场景◆

1.1 AI Agent 的安全挑战

AI Agent 正在从"对话式助手"演进为"自主执行者"——它能够编写代码、调用 API、操作浏览器、执行系统命令。这种自主性在带来效率飞跃的同时，也引入了前所未有的安全挑战：

风险维度	典型场景	潜在影响
代码执行风险	LLM 生成的代码包含恶意操作 (rm -rf /、反向 Shell)	宿主机被攻陷，影响同租户
数据泄露	Agent 将用户隐私/企业机密发送到未授权的外部 API	合规违规、商业损失
凭证滥用	Agent 窃取或滥用 API Key/Token 进行越权操作	资源盗用、服务瘫痪
供应链攻击	Agent pip install 了恶意包，执行了挖矿/后门代码	横向渗透、持久化入侵
逃逸攻击	利用内核漏洞从容器逃逸到宿主机	整个集群沦陷

传统容器方案 (Docker/Containerd) 共享宿主机内核，一旦存在内核漏洞，攻击者可从容器内直接逃逸到宿主机。对于 AI Agent 这种执行不可信代码的场景，共享内核的隔离模型已不再安全。

1.2 网络安全需求

AI Agent 沙箱的网络层需要解决以下核心问题：

◆ 隔离性：沙箱之间、沙箱与宿主机之间的网络必须完全隔离

◆ 可控性：精确控制每个沙箱可以访问哪些外部服务 (IP/域名/协议)

◆ 可观测性：所有出站流量必须可审计、可追溯

◆ 透明性：对 Agent 代码零侵入，不需要修改应用逻辑

◆ 高性能：网络策略不能成为千级并发的瓶颈

◆2. CubeSandbox架构总览◆

2.1 CubeSandbox系统架构

CubeSandbox 采用清晰的分层架构，从上到下依次为 API 网关层、编排调度层、计算节点层和虚拟化层：

2.2 CubeSandbox网络架构

网络数据面包括访问沙箱流量和沙箱外访流量，四层转发及策略执行由高性能的内核态ebpf实现，七层路由及深度检查由由用户态nginx/openresty完成：

◆ 沙箱Ingress流量

◇ CubeProxy：基于nginx/openresty的CubeProxy反向代理，通过http header信息高性能路由转发。

◇ CubeVS(Ingress)：纯内核态ebpf高性能转发，实现portmapping的无状态转换逻辑。

◆ 沙箱Egress流量

◇ CubeVS(Egress)：纯内核态ebpf高性能转发，实现IP过滤、域名过滤、SNAT、会话追踪等沙箱外访能力。

◇ CubeEgress：基于nginx/openresty的CubeEgress的7层代理，实现HTTPS 拦截、凭证注入、访问审计等安全能力，还可以基于lua扩展。

2.3 CubeSandbox宿主机网络管理

network-agent实现TAP池化管理与分配、PortMapping端口分配、转发策略数据下发、状态持久化等管理。

◆ Tap设备池化:预创建500+的Tap设备,沙箱启动时无需初始化Tap设备,减少沙箱创建耗时59+ms。

◆ CubeVS、CubeEgress转发策略配置数据下发管理，按用户定义的策略处理网络流量。

◆CubeSandbox沙箱网络虚拟化：CubeVS◆

3.1 设计目标

传统容器网络方案 (Linux Bridge、OVS、iptables NAT) 的每包处理开销随租户数增长而膨胀。CubeVS 用三个小型 eBPF 程序替代了整条传统网络栈，实现了ARP 代理、策略检查、L7 代理选择、SNAT、会话创建、反向 NAT、端口映射代理、DNAT 到沙箱 IP、保持透明代理源 IP。

◆ 点对点低延迟：每个沙箱独占 TAP 设备，无共享网桥、无软件交换机跳转，没有共享 L2 域，无需 ARP 洪泛和 STP。

◆ 内核态策略执行：网络策略在 eBPF 中执行，CPU 开销最小，性能高，每个 TAP 拥有独立的策略 trie，更新互不影响。

◆ 可扩展 NAT：SNAT 端口分配使用锁保护的水线池 + 冲突检测插入，避免 iptables 规则爆炸。

◆ 安全隔离：TAP 间天然不可达，只能通过 eBPF 程序控制的路径通信

3.2 网络访问控制：基于 LPM Trie 的 CIDR 策略IP过滤

CubeVS 在 eBPF 内核态实现 per-sandbox 的出站 IP 策略，使用 LPM (Longest Prefix Match) Trie 数据结构进行 CIDR 匹配，per-device 设计意味着更新一个沙箱的策略不需要遍历或锁定其他沙箱的 map。

评估顺序：

1. allow_out 中匹配?              → 允许2. deny_out 中匹配?               → 拒绝3. 默认:                          → 允许

优先级：allow > deny > default-allow，可以设置全拒绝 (0.0.0.0/0) 再用 allow 规则逐条放开的细粒度控制。

默认策略

CubeVS默认允许沙箱访问internet，但阻止沙箱访问以下网段以确保沙箱无法访问宿主机内网，但可以通过allow_out放通，也可通过指定策略"allow_internet_access=False"组织沙箱访问internet，相当于deny_out中添加了全拒绝 (0.0.0.0/0) 策略。

CIDR	说明
10.0.0.0/8	私有网络 A 类
127.0.0.0/8	回环地址
169.254.0.0/16	链路本地 (沙箱内部网关所在段)
172.16.0.0/12	私有网络 B 类
192.168.0.0/16	私有网络 C 类

3.3 网络访问控制：基于 LPM Trie 的 DNS报文域名策略过滤

IP 层策略只能基于目标 IP 做 CIDR 匹配，然而 AI Agent 的沙箱网络访问通常以域名为目标 (如 api.openai.com)，且同一域名可能解析到多个不同的 IP，CubeVS 通过 DNS 策略引擎实现域名维度的精细控制，CubeVS 在 eBPF 层拦截 DNS 查询 (UDP 端口 53)，获取查询域名，如果在allow_out中放通了，则创建域名追踪记录，在CubeVS接收到DNS响应报文时，如果匹配上该追踪记录，则将响应报文中的IP地址添加到allow_out中，以放通后续针对该域名的访问流量，并设置TTL以确保删除allow_out中陈旧的IP。

◆ 域名只能在allow_out中放通，不能在deny_out中配置。

◆ 为达到只放通指定域名的流量，建议deny_out中配置全拒绝策略 (0.0.0.0/0) 。

◆ allow_out中配置了域名时，Cube会自动将模版配置的DNS server IP添加到allow_out中。

◆ 限制：该能力依赖沙箱通过UDP port 53的DNS查询获取域名IP后发起访问，而不是其它方式，如配置hosts。

与 L7 策略的协同

DNS域名过滤策略在 eBPF 内核层提供域名维度的控制，CubeEgress在 L7 层提供更精细控制，包括http/https、sni、host、path、method的精确控制。

在沙箱network配置中配置了rules策略时，Cube会自动将其中的host、sni在allow_out中放通域名，并标记对该域名的访问流量将上送到CubeEgress进行L7层处理，如凭证托管、访问审计，或L7层拒绝访问。

◆ eBPF DNS 策略：快速拒绝已知恶意域名，减少到达 L7 代理的流量。

◆ CubeEgress L7 策略：精细的域名通配 (*.example.com)、路径前缀 (/v1/*)、HTTP 方法等条件匹配。

◆4. 沙箱网络入向网关：CubeProxy◆

CubeProxy 是沙箱的入向流量网关，负责将外部请求路由到正确的沙箱实例，基于 OpenResty (Nginx + Lua) 实现，采用Host 头路由，兼容通配符 DNS (*.sandbox.cube.app)，支持 TLS SNI，易于 DNS 配置。

格式：{port}-{sandbox_id}.{domain}

请求: GET /api/v1/status HTTP/1.1Host: 8080-abc123def456.sandbox.cube.app解析: container_port = "8080"      sandbox_id    = "abc123def456"

CubeProxy 通过 Redis 查询沙箱在宿主机上的portmapping信息，即根据(container_port、sandbox_id)获取(HostIP、mapping-port)，将请求转发到对应母机。

◆5. 应用层安全增强：CubeEgress◆

5.1 设计定位

CubeEgress 是沙箱的出向安全网关，在 L7 层对 HTTP/HTTPS 流量实施深度检查。它是对CubeVS 内核态策略的用户态增强层，解决内核层无法处理的域名匹配、凭证注入、内容审计等需求。

核心能力矩阵：

能力	说明
HTTPS 透明拦截	MITM 动态证书 + TLS 终止
域名/路径/方法匹配	L7 策略引擎，first-match-wins
凭证注入	代理层自动注入，Agent 不接触凭证
数据脱敏	审计日志中敏感字段替换
访问审计	JSONL 格式结构化日志
请求过滤	允许或拒绝请求

限制：该能力依赖沙箱通过UDP port 53的DNS查询获取域名IP后发起访问，而不是其它方式，如配置hosts。

5.2 按需引流：eBPF 到 L7 代理的流量调度

不是所有流量都需要 L7 检查，只有访问rules中配置了规则的域名的http/https流量才会通过CubeVS 按需引流到CubeDev设备，从而进入kernel Stack，再结合iptables的TProxy机制和用户态socket设置IP_TRANSPARENT选项(当前nginx/openresty均不支持，Cube提供了patch，也提供了打过patch的openresty容器镜像)，将报文透明转发到OpenResty的用户态socket接收，并保留沙箱访问的原始目的IP。

5.3 HTTPS 透明拦截：动态证书生成

CubeEgress 通过 MITM (Man-in-the-Middle) 代理实现对 HTTPS 流量的深度检查，核心机制是动态证书生成：

证书架构

Root CA (自签, 存储在 /etc/cube/ca/)    ↓ (签名)叶证书 (为每个 SNI 动态生成, 7 天 TTL)

◆ ECDSA P-256：叶证书使用椭圆曲线，比 RSA 更快更小。

◆ 7 天 TTL：短期有效，降低泄露影响。

◆ 缓存锁：lua-resty-lock 防止同一 SNI 并发生成。

◆ CA 信任注入：在制作模版时默认将Root CA 证书注入沙箱，对 Agent 透明。

5.4 L7 策略引擎

沙箱的CubeEgress策略可以包含多个rule，每个rule又包含了一个match和action，顺序匹配，第一个匹配的rule生效，不再匹配后续rule，未匹配任何规则的请求将默认拒绝。

◆ match的匹配语义

​​​​​​​

match = {	sni   = "*.openai.com",       -- 域名匹配 (通配符)                 	host  = "api.openai.com",     -- HTTP Host 头匹配                 method = {"GET", "POST"},     -- HTTP 方法 (任一匹配)                 	path  = "/v1/*",              -- URL 路径前缀匹配                 	scheme = "https"              -- 协议限制             }

字段	格式	语义
sni	"*.example.com"	精确匹配或后缀 *. 通配 (仅匹配子域名)
host	"api.example.com"	精确匹配或后缀 *. 通配 (忽略 :port)
method	{"GET", "POST"}	数组，任一匹配即通过
path	"/v1/*"	精确匹配或尾缀 * 前缀匹配
scheme	"http" / "https"	精确匹配

◆ action的执行语义

​​​​​​​

action = {	allow = true,									-- 是否放通请求            audit = "metadata",							   -- 审计级别        inject = {										-- 凭证注入        	{                	header  = "Authorization",                	secret  = "sk-proj-abc123...",                	format  = "Bearer ${SECRET}"        	}	}}

5.5 凭证托管与注入

AI Agent沙箱不应直接持有 API Key/Token，CubeEgress 的凭证注入机制让 沙箱发送不含凭证的请求，由沙箱外的CubeEgress代理层自动注入：

​​​​​​​

Agent沙箱发送:                       代理注入后发往服务端:POST /v1/chat/completions           POST /v1/chat/completionsHost: api.openai.com                Host: api.openai.comContent-Type: application/json      Content-Type: application/json                                    Authorization: Bearer sk-proj-abc123...

凭证注入受到 多道检查以保护凭证的安全，任一失败则放弃注入（请求仍可继续，但不携带凭证）：

检查内容
请求必须是 HTTPS
SNI 匹配规则
Host 头必须与 SNI一致
上游证书验证通过
策略授权放通

5.6 访问审计

每条网络请求（无论允许还是拒绝）都生成 JSONL (JSON Lines) 格式的结构化审计记录，审计日志中的敏感字段绝不记录原始值，通过多层脱敏策略保护

Header 类型	脱敏策略	示例
Authorization / Proxy-Authorization	保留认证方案，脱敏值	Bearer <redacted:Bearer>
Cookie / Set-Cookie	保留 Cookie 名，脱敏值	<redacted; names=session_id,theme>
X-Api-Key X-Auth-Token Token	完全脱敏	<redacted>
含 token/secret/key/password/auth 的 Header	完全脱敏	<redacted>

5.6 CubeEgress能力扩展

CubeEgress是基于OpenResty实现的http/https透明代理，当前实现了基本的请求过滤/凭证托管/访问审计的能力，如果需要更深入的检测处理或其它能力，可以修改或新增lua脚本轻松扩展，具体可以参考社区仓库文档:

https://github.com/TencentCloud/CubeSandbox/blob/master/docs/zh/guide/security-proxy.md

◆6. 总结◆

CubeSandbox 网络体系通过 "eBPF 内核态 + OpenResty 用户态 " 的组合实现了高性能的网络转发，同时通过资源分配本地化、沙箱配置归一化、资源池化等技术实现了极致的沙箱创建速度，在 AI Agent 安全沙箱这一新兴场景中实现了多项技术创新：

创新点	传统方案	CubeSandbox 方案	优势
网络隔离	Linux Bridge + iptables	点对点 TAP + eBPF	零广播开销、内核态强制
策略执行	iptables 规则链	LPM Trie + eBPF	O(1) 查询、per-sandbox 隔离
域名过滤	应用层代理	内核态ebpf	高性能转发
HTTPS 检查	手动配置证书	动态证书生成 (ECDSA P-256)	零预配置、自动管理
凭证管理	环境变量/配置文件	代理层注入 + 多道安全检查	Agent沙箱不接触凭证
审计日志	文本格式、需解析	JSONL 结构化 + 自动脱敏	合规友好、可直接分析

---

Cube Sandbox 是腾讯云开源的一款基于 RustVMM 与 KVM 构建的高性能、开箱即用的安全沙箱服务。它既支持单机部署，也能方便地扩展到多机集群。对外兼容 E2B SDK，可在 60ms 内创建具备完整服务能力的硬件隔离沙箱，并将内存开销控制在 5MB 以内。