Agent Sandbox 安全隔离：Firecracker microVM 架构与实战

1. 从一次线上事故说起为什么 Agent 需要独立沙箱去年年底我们团队在做一个代码执行类 Agent 产品用户输入一段 Python 脚本Agent 在云端跑完把结果返回。上线第三天就出了事一个用户提交了while True: os.fork()整台 8 核 16G 的宿主机在十几秒内被 fork 炸弹打满连带上面跑的其他十几个租户任务全部挂掉。事后复盘根因很清楚——我们把不可信代码直接扔进了宿主机上的 Docker 容器而 Docker 共享内核这个事实决定了容器逃逸和资源耗尽这两件事本质上只能靠 cgroup 和 seccomp 去缓解没法从架构上隔离。这次事故之后我们开始认真评估 microVM 方案最终落到 Firecracker 上。这篇文章就把我们踩过的坑、Firecracker 的运行路径、以及 Agent Sandbox 的安全边界怎么划完整讲一遍。如果你正在做 Agent 执行环境、在线判题、CI 沙箱、或者任何需要跑不可信代码的场景这篇应该能帮你少走几个月弯路。先说清楚 Firecracker 是什么它是 AWS 开源的轻量级虚拟机监视器VMM用 Rust 写的专门为 serverless 和容器类负载设计。它基于 KVM 做硬件虚拟化每个 microVM 有自己独立的内核启动时间可以压到 125ms 左右内存开销大概 5MB 起步。跟 QEMU 比它砍掉了大量用不上的设备模拟只保留 virtio 系列的最小子集所以攻击面小得多。Agent Sandbox 要的就是这个——每个用户任务一个独立内核跑完即销毁互不影响。2. Firecracker 的整体架构与运行路径拆解2.1 三层结构KVM、VMM、Guest理解 Firecracker 的运行路径得先把它拆成三层来看。最底层是KVMLinux 内核自带的虚拟化模块。它负责把 CPU 的虚拟化指令Intel VT-x / AMD-V暴露给用户态程序同时管理内存的二级页表EPT/NPT。Firecracker 本身不碰硬件它通过/dev/kvm这个字符设备跟 KVM 打交道用ioctl下发创建 vCPU、设置内存区域、注入中断这些命令。中间层是Firecracker VMM也就是那个 Rust 二进制。它做三件事解析配置、创建 microVM、处理 virtio 设备请求。它不模拟显卡、不模拟网卡硬件、不模拟 USB只提供 virtio-net、virtio-block、virtio-vsock 这几个设备。设备少意味着代码路径短代码路径短意味着漏洞少。最上层是Guest也就是跑在 microVM 里的那个 Linux 内核加 rootfs。它看到的是一个标准的 virtio 设备环境内核里加载 virtio 驱动就能用。Guest 完全不知道自己在虚拟机里也不需要知道。2.2 一次请求的完整生命周期我拿我们线上的一次真实调用举例把路径串起来。用户提交代码后调度器选一台宿主机通过 Firecracker 的 API socket 发一个PUT /machine-config指定 vCPU 数量、内存大小。然后PUT /boot-source指定内核镜像路径和启动参数PUT /drives挂载 rootfsPUT /network-interfaces配置网络。最后InstanceStart一按microVM 开始跑。Guest 内核启动后init 进程拉起我们的 agent-runner它从 vsock 或者串口读任务、执行、把结果写回去。执行完宿主机侧直接kill掉 Firecracker 进程microVM 连同它的内存、磁盘快照一起消失。整个过程从 API 调用到任务开始执行我们实测 P50 在 180ms 左右P99 大概 400ms。这个数字对 Agent 场景是可以接受的——用户感知不到但隔离强度是容器给不了的。2.3 为什么是 virtio而不是设备直通有人会问既然要性能为什么不搞 PCI 直通VFIO答案在 Agent Sandbox 的场景里很明确直通意味着把物理设备暴露给不可信代码攻击面直接爆炸。而且直通需要 IOMMU 支持宿主机配置复杂热迁移也做不了。virtio 是一套半虚拟化协议Guest 和 Host 通过共享内存环virtqueue通信Host 侧由 Firecracker 处理请求。它不模拟真实硬件所以没有那些历史遗留的寄存器兼容性问题。virtio 的驱动在 Linux 内核里是标准组件稳定性和性能都经过大规模验证。对我们来说virtio-net 提供网络、virtio-block 提供磁盘、virtio-vsock 提供 Host-Guest 通信通道三件套足够覆盖 Agent 的所有需求。3. 安全边界到底划在哪四层防御模型3.1 第一层KVM 硬件隔离这是最硬的一层。每个 microVM 有独立的地址空间Guest 的代码跑在 ring 3或者 ring 0 但被 KVM 拦截它想访问宿主机内存必须经过 EPT 页表映射。没映射的地址硬件直接抛异常。这跟容器共享内核有本质区别——容器里的进程理论上可以通过内核漏洞提权到宿主机而 microVM 要逃逸得先攻破 Guest 内核再攻破 KVM再攻破 Firecracker难度是指数级上升的。我们做过一个测试在 Guest 里跑一段恶意代码尝试读写宿主机物理内存。结果是 KVM 直接触发EXIT_REASON_EPT_VIOLATIONFirecracker 收到退出原因后选择终止 microVM。整个过程宿主机侧没有任何异常。3.2 第二层Firecracker 的最小设备面Firecracker 的代码量大概 5 万行 Rust对比 QEMU 的百万行 C 代码攻击面小了两个数量级。它默认不启用任何非必要设备连 PCI 总线都是可选的。我们线上配置里只开了 virtio-net、virtio-block、virtio-vsock 和串口用于日志其他全部关闭。这里有个实操细节Firecracker 的 API socket 默认是 Unix domain socket权限要设成0600只有调度器进程能访问。千万别图省事监听 TCP那等于把 microVM 的管理接口暴露到网络上。3.3 第三层Guest 内核加固microVM 里的内核也是攻击面。我们用的是自己裁剪的 5.10 LTS 内核关掉了所有用不上的驱动和子系统只保留 virtio、ext4、网络栈。启动参数里加了consolettyS0、panic1、rebootk意思是 panic 后立即重启实际上我们配置成直接退出。Guest 里还要做一层 seccomp 和 cgroup。虽然 microVM 已经隔离了但 Guest 内部如果跑多个任务还是需要限制。我们的做法是每个 microVM 只跑一个任务跑完就销毁所以 Guest 内部不做复杂隔离只用一个非 root 用户跑 agent-runner。3.4 第四层资源配额与生命周期这层是防资源耗尽的。Firecracker 支持给每个 microVM 设置 vCPU 数量、内存上限、磁盘 IO 限速、网络限速。我们线上默认配置是 2 vCPU、512MB 内存、磁盘读写各 100MB/s、网络 50Mbps。超了会被 Firecracker 的 rate limiter 直接限流不会影响宿主机上其他 microVM。生命周期管理上我们给每个 microVM 设了硬超时任务执行超过 30 秒宿主机侧直接 kill。这个超时是宿主机侧控制的Guest 里的代码改不了防止用户提交死循环。4. 从零搭一个 Agent Sandbox完整实操流程4.1 环境准备与内核编译宿主机要求Linux 4.14支持 KVMCPU 有 VT-x/AMD-V。检查命令ls /dev/kvm grep -E vmx|svm /proc/cpuinfo如果/dev/kvm不存在说明 KVM 模块没加载或者 BIOS 里没开虚拟化。内核镜像我们用的是 Firecracker 官方提供的vmlinux示例但生产环境建议自己编译。编译配置里必须打开CONFIG_VIRTIO_MMIO、CONFIG_VIRTIO_BLK、CONFIG_VIRTIO_NET、CONFIG_VIRTIO_VSOCKETS。裁剪完的内核大概 2MB 左右。rootfs 我们用 ext4 格式里面放一个最小的 busybox 加我们的 agent-runner。制作流程dd if/dev/zero ofrootfs.ext4 bs1M count128 mkfs.ext4 rootfs.ext4 mkdir /mnt/rootfs mount rootfs.ext4 /mnt/rootfs # 拷贝 busybox、agent-runner、必要的库 umount /mnt/rootfs4.2 Firecracker 配置与启动Firecracker 的配置通过 API 下发我写成一个 shell 脚本方便复用API_SOCKET/tmp/firecracker.sock rm -f $API_SOCKET firecracker --api-sock $API_SOCKET --no-api # 配置机器 curl --unix-socket $API_SOCKET -X PUT http://localhost/machine-config \ -H Content-Type: application/json \ -d {vcpu_count: 2, mem_size_mib: 512} # 配置内核 curl --unix-socket $API_SOCKET -X PUT http://localhost/boot-source \ -H Content-Type: application/json \ -d {kernel_image_path: ./vmlinux, boot_args: consolettyS0 panic1} # 配置 rootfs curl --unix-socket $API_SOCKET -X PUT http://localhost/drives/rootfs \ -H Content-Type: application/json \ -d {drive_id: rootfs, path_on_host: ./rootfs.ext4, is_root_device: true, is_read_only: false} # 启动 curl --unix-socket $API_SOCKET -X PUT http://localhost/actions \ -H Content-Type: application/json \ -d {action_type: InstanceStart}这里有个坑is_read_only如果设成 trueGuest 里就没法写文件很多任务会失败。但设成 false 又意味着 Guest 可以改 rootfs。我们的做法是每个任务用一份 rootfs 的 copy-on-write 副本跑完直接删这样既保证可写又保证隔离。4.3 网络配置tap 设备与 NATFirecracker 的网络通过 tap 设备接入宿主机。创建 tapip tuntap add dev tap0 mode tap ip addr add 172.16.0.1/30 dev tap0 ip link set tap0 up然后在 Firecracker 配置里指定curl --unix-socket $API_SOCKET -X PUT http://localhost/network-interfaces/eth0 \ -H Content-Type: application/json \ -d {iface_id: eth0, host_dev_name: tap0, guest_mac: AA:FC:00:00:00:01}Guest 里配172.16.0.2/30网关172.16.0.1。宿主机上开 NAT 让 Guest 能出网iptables -t nat -A POSTROUTING -s 172.16.0.0/30 -o eth0 -j MASQUERADE注意生产环境一定要给每个 microVM 分配独立的 /30 网段否则多个 microVM 之间会 IP 冲突。我们用一个 IP 池管理器来分配和回收。4.4 任务下发与结果回收Host 和 Guest 之间的通信我们走 vsock比串口快比网络简单。Guest 里 agent-runner 监听 vsock 端口Host 侧用socat或者自己写的客户端连接。# Host 侧连接 Guest 的 vsock socat - UNIX-CONNECT:/tmp/firecracker.sock实际上 Firecracker 的 vsock 是通过 Unix socket 代理的配置里指定uds_path然后 Host 侧连这个 UDS 就能跟 Guest 通信。任务格式我们用 JSON{code: ..., timeout: 30, language: python}。Guest 侧执行完把{stdout: ..., stderr: ..., exit_code: 0}写回去。5. 性能调优与踩坑实录5.1 启动速度优化Firecracker 官方说 125ms 启动我们实测冷启动 180ms 左右。差距主要在 rootfs 挂载和 init 进程。优化手段有几个一是用snapshot。Firecracker 支持把运行中的 microVM 快照下来下次直接从快照恢复跳过内核启动。我们实测恢复时间能压到 30ms 以内。但快照有个问题恢复出来的 microVM 内存状态是固定的如果任务需要干净环境得在恢复后做一次 reset。二是精简 init。我们把 init 换成一个静态编译的 C 程序只做三件事挂载 /proc、启动 agent-runner、等待。比 systemd 快得多。三是 rootfs 用内存盘。如果任务不需要持久化直接把 rootfs 加载到 tmpfs读写都在内存里快且干净。5.2 常见问题速查表问题现象可能原因排查方法解决方案microVM 启动后无输出内核参数错误或 rootfs 损坏检查boot_args里的 console 配置用consolettyS0并确认 rootfs 可挂载网络不通tap 设备未配置或 NAT 缺失ip addr show tap0、iptables -t nat -L补全 tap 配置和 MASQUERADE 规则启动报 KVM 错误/dev/kvm 权限不足ls -l /dev/kvm把运行用户加入 kvm 组任务超时未终止超时逻辑在 Guest 侧检查宿主机侧是否有硬超时宿主机侧加 kill 定时器内存占用持续增长microVM 未正确销毁ps auxgrep firecracker5.3 几个血泪教训第一个坑忘了关 API socket 的 TCP 监听。早期版本我们图方便让 Firecracker 监听 TCP结果被扫描到有人尝试调 API 改配置。后来全部改成 Unix socket 加权限控制。第二个坑rootfs 共享导致数据泄露。一开始多个 microVM 共用一份 rootfs结果 A 任务写的临时文件被 B 任务读到了。改成每个任务独立副本后解决。第三个坑vsock 缓冲区溢出。任务输出特别大时比如打印十万行日志vsock 缓冲区会满导致 Guest 侧阻塞。后来加了流控Host 侧边读边落盘不积压。第四个坑快照恢复后的时钟漂移。从快照恢复的 microVM系统时钟还是快照时刻的导致 TLS 握手失败。解决方法是恢复后立即用 vsock 同步一次时间。6. 安全边界的再思考哪些事 Firecracker 也防不住Firecracker 很强但不是银弹。有几类攻击它防不住得靠其他手段。侧信道攻击。Spectre、Meltdown 这类基于 CPU 推测执行的攻击理论上可以跨 microVM 泄露数据。缓解手段是内核打补丁、关闭 SMT超线程但会损失性能。我们的选择是接受这个风险因为 Agent 场景下用户数据敏感度没那么高而且攻击成本极高。Guest 内核漏洞。如果 Guest 内核有提权漏洞攻击者可以在 Guest 内提权到 root。但这只是 Guest 的 root要逃逸到宿主机还得再攻破 KVM 和 Firecracker。所以 Guest 内核要及时更新安全补丁。资源耗尽型攻击。虽然 Firecracker 有限流但如果攻击者用合法请求打满 CPU还是会影响同宿主机上的其他 microVM。我们的做法是宿主机上限制同时运行的 microVM 数量留出余量。供应链攻击。如果 rootfs 里的 agent-runner 被篡改那隔离就形同虚设。所以 rootfs 要签名校验启动时验证哈希。7. 写在最后一些个人体会搞了半年多 Agent Sandbox最大的感受是安全隔离没有银弹只有层层设防。Firecracker 给了我们一个很强的底座但真正让系统稳的是那些看起来不起眼的细节——API socket 的权限、rootfs 的副本策略、宿主机侧的硬超时、vsock 的流控。如果让我给刚入坑的人一个建议那就是先把威胁模型想清楚再选技术。你的 Agent 跑的是完全不可信的用户代码还是半可信的内部代码前者必须上 microVM后者容器加 seccomp 可能就够了。别为了技术而技术Firecracker 的运维复杂度比 Docker 高一个量级团队得有相应的人力储备。另外Firecracker 的社区很活跃但文档相对简略很多细节得看源码或者翻 issue。我建议先把官方的那几个示例跑通再逐步改造成自己的形态。别一上来就搞快照、搞热迁移那些是优化阶段的事先把基本路径跑稳。最后分享一个小技巧调试 microVM 时把串口输出重定向到文件firecracker --api-sock ... 21 | tee vm.log这样 Guest 内核的启动日志、panic 信息都能看到比盲猜快得多。