1. 为什么“能跑起来”和“跑得安全”是两码事做过代码执行平台、在线评测系统、CI 流水线或者 AI Agent 工具调用的人大概率都经历过这样一个阶段一开始只想着怎么把用户提交的代码跑起来docker run一把梭能出结果就行。等到平台稍微有点规模或者接入了不可信来源的代码才发现真正的麻烦根本不在“能不能跑”而在“跑的时候它到底能碰到什么”。这就是Tool 的安全性与执行沙箱要解决的核心问题。所谓 Tool在这里泛指一切需要被调度执行的代码单元——用户提交的脚本、AI Agent 动态生成的函数、插件市场里的第三方扩展、在线 IDE 里的编译任务。它们有一个共同特征来源不可信但必须在本机或集群里真实执行。执行沙箱就是夹在“不可信代码”和“宿主环境”之间的那层隔离带。我见过太多项目在这件事上翻车。有的用 Docker 跑用户代码结果容器里挂载了宿主机的 Docker socket用户一行docker run -v /:/host就把整台机器读了个遍有的图省事直接用subprocess起进程连基本的资源限制都没有一个while True: fork()就能把机器打挂还有的虽然上了容器但网络没隔离用户代码直接扫内网、打元数据接口。这些都不是理论风险是真实发生过的。这篇文章面向的是需要自己搭建代码执行环境的后端工程师、平台开发者、AI Agent 基础设施同学以及任何在做“让别人的代码在我这儿跑”这件事的人。我会从 Docker 的默认隔离能力讲起说清楚它的边界在哪里然后重点拆解 gVisor 这类用户态内核沙箱是怎么补上这些短板的最后给出一套可以照着搭的分层防御架构。全程讲人话参数和配置都给到能直接抄的程度。先给一个整体判断方便你建立预期Docker 是“进程级隔离的加强版”gVisor 是“系统调用级的隔离”两者不是替代关系而是纵深防御的不同层次。理解了这句话后面的选型和架构就顺了。2. Docker 沙箱的能力边界它到底防住了什么2.1 容器隔离的底层原理用一句话说清很多人把容器当成“轻量级虚拟机”这是个危险的误解。容器本质上是宿主机上的一个普通进程只不过借助 Linux 的 Namespace 和 Cgroups 这两套机制让它“看起来”像一台独立机器。Namespace 负责“看不见”PID namespace 让它看不到别的进程Network namespace 给它独立的网卡和路由表Mount namespace 给它独立的文件系统视图User namespace 可以做 UID 映射。Cgroups 负责“用不了那么多”限制 CPU、内存、磁盘 IO、进程数。关键点在于这些被隔离的进程和宿主机上其他进程共享同一个 Linux 内核。系统调用是直接打到宿主内核上的。这就决定了容器的安全边界——它防的是“进程之间的相互干扰”而不是“恶意代码对内核的攻击”。打个比方Docker 像是把一群人关进不同的房间房间之间墙很厚互相看不见也听不到。但所有人用的都是同一套水电系统内核如果有人往水管里投毒利用内核漏洞提权整栋楼都遭殃。2.2 Docker 默认配置下哪些攻击面是敞开的我整理了一张表是实际做安全评估时最常发现的几个问题按危险程度排序风险项默认行为后果危险等级以 root 运行容器内默认 UID 0配合内核漏洞可直接提权到宿主 root极高挂载 Docker socket不挂载但很多人手动挂用户可创建特权容器逃逸极高特权模式关闭若开启则几乎无隔离极高内核漏洞利用无防护通过 CVE 提权逃逸高资源无限制无限制fork 炸弹、内存耗尽打挂宿主高网络可达内网默认 bridge 可出网扫描内网、访问元数据服务中高Capabilities 过多默认保留一批部分能力可被滥用中文件系统可写可写持久化恶意文件中这张表里最要命的是前两项。我见过一个在线代码平台为了让用户代码能“构建镜像”直接把/var/run/docker.sock挂进了执行容器。结果就是任何用户都能通过这个 socket 创建一个挂载宿主机根目录的特权容器等于把整台服务器的钥匙交出去了。这个设计在功能上很“方便”在安全上等于零。2.3 一个“看起来安全”的 Docker 配置长什么样先给一个我实际在用的基础配置作为后面讨论的基准。这个配置能挡住大部分低级攻击但挡不住内核漏洞docker run \ --rm \ --network none \ --read-only \ --tmpfs /tmp:rw,noexec,nosuid,size64m \ --memory 256m \ --memory-swap 256m \ --cpus 0.5 \ --pids-limit 64 \ --user 65534:65534 \ --cap-drop ALL \ --security-opt no-new-privileges \ --security-opt seccompdefault.json \ --ulimit nofile256:256 \ runner-image:latest逐条解释为什么这么配--network none直接断网。如果业务确实需要联网比如装依赖应该走一个受控的代理而不是放开整个网络。--read-only--tmpfs /tmp根文件系统只读只给一个小的可写临时目录且noexec防止在 tmp 里执行下载的二进制。--memory和--memory-swap设成一样禁用 swap避免内存超限时用磁盘顶导致性能雪崩。--pids-limit 64这是防 fork 炸弹的关键没有它一个:(){ :|: };:就能把宿主进程表打满。--user 65534用 nobody 用户跑即使容器内被攻破也不是 root。--cap-drop ALL把所有 Linux capabilities 全删掉需要哪个再加哪个。--security-opt no-new-privileges禁止通过 setuid 程序提权。--security-opt seccompdefault.json用 seccomp 过滤系统调用Docker 默认的 seccomp profile 已经禁掉了一批危险调用。这套配置下来Docker 的隔离能力基本被榨干了。但请注意它依然共享宿主内核。如果攻击者手里有一个能绕过 seccomp 的内核提权漏洞比如某些 io_uring 相关的 CVE这套配置是挡不住的。这就是为什么我们需要 gVisor。提示--cap-drop ALL之后如果程序报权限错误不要急着加回--privileged而是精确地加回单个 capability比如--cap-add NET_BIND_SERVICE。加--privileged等于前面所有努力白费。3. gVisor 的防御思路给系统调用加一层“翻译官”3.1 用户态内核到底是个什么东西gVisor 的核心思想用一句话概括不让不可信代码直接和宿主内核对话而是在中间插一个用 Go 写的“假内核”。传统容器里用户程序调用open()、read()、socket()这些系统调用请求直接进入宿主 Linux 内核。gVisor 则拦截这些调用交给它自己实现的用户态内核叫 Sentry处理。Sentry 用 Go 写内存安全即使被攻击也很难拿到宿主内核的执行权。这个架构有个形象的类比Docker 像是让外国人和本地人直接对话语言不通就可能产生误解甚至冲突gVisor 像是配了一个翻译官所有对话都经过翻译翻译官听不懂的不支持的调用就直接拒绝翻译官觉得危险的敏感操作就拦下来。具体来说gVisor 的架构分三层Sentry用户态内核负责处理绝大部分系统调用管理进程、内存、文件系统。Gofer文件系统代理Sentry 不直接碰宿主文件系统而是通过 Gofer 这个独立进程转发文件操作进一步隔离。PlatformSentry 和宿主内核的接口层可以是 ptrace、KVM 或者 systrap。这个设计带来的直接好处是宿主内核暴露给不可信代码的攻击面被压缩到了极小。Sentry 只用到宿主内核的一小部分系统调用而且这些调用是经过精心筛选的。攻击者想通过内核漏洞逃逸得先突破 Sentry 这一层难度陡增。3.2 gVisor 和 Docker 的隔离强度对比我把两者的关键差异整理成表方便你判断什么时候该上 gVisor维度DockerruncgVisor隔离层次进程级NamespaceCgroups系统调用级用户态内核内核攻击面完整宿主内核极小仅 Sentry 用到的调用系统调用兼容性100%约 70-80%部分不支持性能开销接近原生系统调用密集场景明显变慢启动速度快略慢内存占用低每个沙箱多几十 MB适用场景可信度较高的代码完全不可信的代码这里要重点说清楚兼容性和性能的代价因为这是选型时最容易踩的坑。gVisor 不是完整的 Linux 实现它只实现了常用系统调用的子集。我实测下来纯计算类任务比如跑个 Python 脚本做数据处理基本无感但涉及大量系统调用的场景比如频繁的文件 IO、网络密集型的服务、依赖特定内核特性的程序就可能出问题。最典型的是某些依赖io_uring的高性能 IO 程序跑不起来。部分需要特定/proc或/sys内容的程序会读到不完整的信息。一些用了冷门系统调用的二进制直接报ENOSYS。性能方面系统调用密集的负载下gVisor 的开销可能到 2-5 倍。纯 CPU 计算的开销则小得多。所以我的经验是不要无脑全量上 gVisor而是按代码可信度分层。3.3 什么时候该用 gVisor什么时候 Docker 就够了给一个我实际使用的判断标准完全不可信、来源开放用户提交代码、AI 生成代码、第三方插件上 gVisor性能损失换安全。半可信、有审核内部团队代码、经过扫描的依赖Docker 加固配置足够。可信、性能敏感自家服务、核心业务普通容器甚至裸进程重点在资源隔离。这个分层不是拍脑袋而是基于“攻击者能力和动机”的评估。开放平台的攻击者动机最强、能力参差不齐必须用最强隔离内部代码的攻击面主要来自供应链投毒Docker 加固 镜像扫描能覆盖大部分。注意gVisor 不是银弹。它自己也有 CVE历史上出过逃逸漏洞。所以正确的姿势是把它作为纵深防御的一层而不是唯一依赖。后面会讲怎么组合。4. 从零搭一套分层防御架构4.1 整体架构设计四层防御我实际部署的架构分四层从外到内依次收紧第一层调度层隔离。执行任务不直接跑在业务服务器上而是跑在独立的执行节点池里。这些节点除了执行沙箱不跑任何其他业务即使被攻破影响范围也被限制在节点池内。第二层容器运行时隔离。用 gVisor 作为 runc 的替代运行时通过--runtimerunsc指定。这一层负责系统调用级别的隔离。第三层容器配置加固。就是前面那套--network none、--read-only、--cap-drop ALL的组合负责资源限制和权限收敛。第四层应用层管控。包括执行超时、输出大小限制、代码静态扫描、行为监控。这一层在沙箱之外负责发现异常并终止。这四层的关系是外层被突破还有内层兜底内层出问题还有监控发现。任何单层都不是绝对可靠但叠起来就形成了足够的防御纵深。4.2 gVisor 的安装与运行时配置安装 runsc 的步骤以 Ubuntu 为例# 下载并安装 runsc curl -fsSL https://storage.googleapis.com/gvisor/releases/release/latest/x86_64/runsc -o runsc chmod x runsc sudo mv runsc /usr/local/bin/ # 配置 Docker 使用 runsc 运行时 sudo runsc install sudo systemctl restart dockerrunsc install会自动往 Docker 的配置文件里写入运行时定义。装完之后验证一下# 用 runsc 跑一个容器确认生效 docker run --rm --runtimerunsc hello-world # 查看运行时列表 docker info | grep -i runtime如果docker info里能看到runsc说明配置成功。接下来跑一个真实的执行任务docker run \ --rm \ --runtimerunsc \ --network none \ --read-only \ --tmpfs /tmp:rw,noexec,nosuid,size64m \ --memory 256m \ --cpus 0.5 \ --pids-limit 64 \ --user 65534:65534 \ --cap-drop ALL \ --security-opt no-new-privileges \ runner-image:latest \ python3 /tmp/code.py注意这里--runtimerunsc是唯一和之前不同的地方其他加固配置照旧。gVisor 和 Docker 加固配置是叠加关系不是二选一。4.3 关键参数的计算与选择过程参数不能拍脑袋定得根据实际负载算。我拿一个 Python 代码执行场景举例。内存限制怎么定先统计正常任务的 P99 内存占用。假设测下来是 180MB那限制设 256MB 留出余量。太小会误杀正常任务太大则失去保护意义。可以用docker stats或者 cgroup 的memory.peak来采集。CPU 限制怎么定如果任务是短时计算用--cpus 0.5限制单核一半。如果是多线程任务要考虑--cpuset-cpus绑定到特定核心避免和其他任务抢。注意--cpus是软限制CPU 空闲时任务可以超用要硬限制得配合 cgroup 的 quota。超时怎么定容器层面用--stop-timeout控制优雅停止时间但真正的执行超时应该在应用层控制。我的做法是应用层设一个总超时比如 30 秒到点直接docker kill不给恶意代码拖延的机会。pids-limit 怎么定正常单线程 Python 任务也就几个进程设 64 足够。如果任务本身要 fork 子进程比如调用编译器得适当放宽但绝不能设成无限制。这些参数没有万能值核心方法是先测量正常负载的分布再按 P99 加余量设定最后用压测验证不会误杀。4.4 网络隔离的实操细节--network none是最彻底的隔离但很多场景需要联网装 pip 包、调外部 API。这时候不能简单放开而是要走受控通道。我的做法是给执行容器配一个专用的 bridge 网络然后用 iptables 规则限制它只能访问特定的代理服务# 创建专用网络 docker network create --internal exec-net # 容器接入该网络--internal 表示不能访问外网 docker run --network exec-net ... # 在代理容器上做白名单转发 # 只允许访问 pypi 等必要域名--internal这个参数很关键它创建的 bridge 网络默认没有到外网的 NAT 规则容器只能和同网络内的其他容器通信。然后你在这个网络里放一个代理容器由它来做域名白名单和流量审计。这样即使代码想扫内网也扫不到东西。提示千万别用默认的 bridge 网络跑不可信代码。默认 bridge 下容器能访问宿主机所在网段云环境里还能摸到元数据服务169.254.169.254这是很多逃逸案例的起点。5. 常见问题与排查技巧实录5.1 gVisor 下程序跑不起来怎么办这是上 gVisor 后最高频的问题。典型症状是程序报operation not permitted或者function not implemented。排查思路第一步确认是不是系统调用不支持。用strace在普通容器里跑一遍看程序用了哪些调用然后对照 gVisor 的支持列表。gVisor 官方有一份兼容性文档列出了已实现和未实现的调用。第二步如果是文件系统相关的问题检查是不是 Gofer 的路径映射有问题。gVisor 的文件访问走 Gofer某些特殊的挂载方式可能不兼容。第三步如果确认是 gVisor 不支持有几个选择换用 ptrace 平台兼容性更好但更慢、降级到普通 runc、或者改写程序避开那个调用。我的经验是大部分问题出在冷门系统调用和特殊文件系统上纯业务代码很少踩到。5.2 容器被 OOM Kill 但内存没超这个坑我踩过。现象是容器莫名其妙被杀docker inspect看到OOMKilled: true但监控显示内存没到限制。原因通常是内存统计口径问题cgroup 统计的是包括 page cache 在内的总内存程序实际用的堆内存可能远小于限制但加上文件缓存就超了。swap 没禁用如果--memory-swap没设成和--memory一样容器可能用 swap导致行为异常。子进程内存没算进去如果程序 fork 了子进程子进程的内存也计入 cgroup。解决办法是设--memory-swap等于--memory禁用 swap然后用--memory-reservation设一个软限制让内核在接近硬限制时先回收缓存。5.3 排查速查表症状可能原因排查命令解决方向容器启动即退出入口命令错误/权限不足docker logs检查 CMD 和用户权限报 ENOSYSgVisor 不支持该系统调用strace换运行时或改代码OOMKilled 但内存没满page cache 计入/swap 未禁docker inspect禁用 swap调 reservation网络不通--network none或 internaldocker exec ip addr检查网络配置文件写入失败--read-only未给可写目录docker inspect加 tmpfs 挂载执行超时被杀应用层超时触发查应用日志调整超时或优化代码权限被拒cap-drop 过度docker exec capsh --print精确加回 capability5.4 几个血泪教训教训一不要相信“内部代码”。我曾经在一个内部平台放松了隔离觉得都是自己人写的代码。结果一个同事从网上抄了段脚本里面藏了个挖矿程序直接把执行节点跑满了。代码来源的可信度和写代码的人无关和代码本身有关。教训二日志和输出也要限制。有次一个用户代码疯狂往 stdout 打日志把磁盘写满了导致整个节点不可用。后来加了输出大小限制比如最多 1MB超了就截断。教训三镜像本身要扫描。执行用的基础镜像如果带了有漏洞的依赖等于把漏洞送进了沙箱。我们后来接入了镜像扫描每次构建都过一遍 CVE 检查。教训四监控比防御更重要。再好的防御也可能被绕过关键是能不能及时发现。我们在执行节点上部署了行为监控一旦发现异常的系统调用模式、异常的网络连接尝试立即告警并隔离节点。6. 写在最后的一点个人体会这套架构我从最初的裸 Docker 一路演进到 gVisor 分层防御中间踩的坑能写一本书。最大的体会是安全不是加一个组件就完事而是一整套思维方式。每次设计执行流程都要问自己三个问题这段代码最坏能做什么如果它真做了我的哪一层能挡住挡住了之后我怎么知道gVisor 确实是目前开源方案里在隔离强度和性能之间平衡得比较好的选择。但它不是终点也不是唯一答案。Firecracker 这类 microVM 方案在隔离性上更强代价是启动更慢、资源占用更高seccomp 和 AppArmor 这类内核自带的机制配置得当也能提供不错的防护。选型的关键是搞清楚你的威胁模型——你到底在防谁防到什么程度。最后分享一个我一直在用的小技巧给每个执行任务打上唯一标签把容器 ID、任务 ID、用户 ID 关联起来。这样一旦出问题能快速定位是哪个任务、哪个用户触发的排查效率提升非常明显。这个习惯帮我省了无数次翻日志的时间。