专题演讲嘉宾：李博康  

AI Agent 和代码沙箱正在成为云上最危险的工作负载——它们执行 LLM 生成的代码、调用任意外部工具、访问未知 API，天然不可信。传统 Kubernetes NetworkPolicy 面对这类场景几乎失效：无法控制域名、无法应对大规模沙箱的策略爆炸、更无法感知 HTTP 层的 Token 和内容。

本演讲以阿里云 ACK 在生产环境的实践为主线，分三个层次展开：首先分析 Agent 沙箱场景独特的网络安全威胁模型；其次介绍我们自研的 TrafficPolicy CRD，如何通过 FQDN 域名白名单、优先级策略叠加和多链路规模化下发，解决当前生产中的隔离问题；最后介绍的计划上线的 L7 策略层——SandboxSecurityProfile，从流量隔离走向 Token 替换、内容审计、LLM 流量治理的完整安全管道。

演讲提纲：

1. Agent 沙箱为什么是个网络安全难题
   • 沙箱工作负载的特殊性：执行不可信代码、工具调用目标运行时才确定、每个租户独立隔离
   • 三类核心威胁：
     • 横向渗透（沙箱访问集群内其他服务）
     • 数据外泄（带着平台凭证访问任意外部 API）
     • 凭证滥用（Agent 直接使用 AK/Token 调用云 API，无法审计）
   • 为什么 NetworkPolicy 不够用：只有 IP/Port、无法做域名白名单、策略数量随沙箱规模线性爆炸
   • 为什么 Envoy sidecar 又太重：数千沙箱并发时资源开销不可接受
2. TrafficPolicy：今天在生产中如何做
   • API 设计理念：声明式、优先级叠加、Namespace 级与集群级双模型
     • GlobalTrafficPolicy 设置平台安全基线，TrafficPolicy 让租户叠加工具白名单
   • 三类访问目标：CIDR / Service（含 Endpoint 展开）/ FQDN
     • FQDN 的挑战：DNS TTL 竞态、IP 动态变化、多租户 DNS 归属难以区分
     • 解法：DNS 拦截 + IP 集合动态追踪 + TTL 陈旧缓存兜底
   • 规模化挑战与下发链路设计：
     • 数千沙箱并发 → nftables 规则集线性膨胀，编译和写入耗时直接影响启动时间
     • 三种部署形态并存（普通节点 / Kata 安全沙箱 / ECI 无节点），无法用同一条链路覆盖
     • 三条差异化路径：gRPC server-streaming 推增量、Shim 在进程启动前预置数据面保证首包前策略就绪、unix socket 旁路 API 处理 ECI 场景
3. SandboxSecurityProfile：L7 治理的下一步
   • 为什么需要 L7：光有"能不能访问"不够，还需要"访问时做什么"
   • 展示 API 设计，逐段解释每个 action 的动机：
     • CloudSecurityCheck：接入云安全中心，实时检测恶意域名
     • IdentityInjection：每个沙箱注入身份标识，流量全程可溯源
     • TokenTransformation：AK/Token 不下发给 Agent，由平台在流量层透明替换
     • LLMAudit：LLM 请求/响应内容审计，满足合规要求
     • Forwarding：强制走内部 LLM 网关，防止绕过管控直接访问外部模型 API
   • 技术实现路径：TLS 拦截（MITM CA）+ Envoy ext_proc 作为可插拔执行引擎
   • 与 TrafficPolicy 的关系：L4 是门，L7 是门里的检查站，两层叠加互补
4. 总结

听众收益：

• 建立 AI Agent/沙箱场景网络安全的完整威胁模型认知
• 了解大规模沙箱场景下网络策略的工程挑战与解法
• 看到一个面向 AI Agent 的 L7 安全策略的完整实现方案