沙箱
选择正确的隔离模式来运行工作流代码
工作流代码——代码步骤和 Piece 动作——始终在包装引擎进程的沙箱中运行。AP_EXECUTION_MODE 决定使用哪种沙箱，这是自托管部署中最关键的安全选择：它决定了恶意工作流是局限在一个 Worker Pod 内，还是可以影响到内核。
执行模式
| 模式 | 支持 Code Piece 中的 NPM | 需要 Docker 特权模式 | 性能 | 多租户安全 | 可重用 Workers | 环境变量 |
|---|---|---|---|---|---|---|---|
| V8/代码沙箱 | ❌ | 否 | 快速且轻量 | ✅ | ✅ | 设置 AP_EXECUTION_MODE 为 SANDBOX_CODE_ONLY |
| 无沙箱 | ✅ | 否 | 快速且轻量 | ❌ | ✅ | 设置 AP_EXECUTION_MODE 为 UNSANDBOXED |
| 内核命名空间沙箱 | ✅ | 是 | 慢且 CPU 密集 | ✅ | ❌ | 设置 AP_EXECUTION_MODE 为 SANDBOX_PROCESS |
| 组合沙箱 | ❌ | 是 | 中等且 CPU 密集 | ✅ | ✅ | 设置 AP_EXECUTION_MODE 为 SANDBOX_CODE_AND_PROCESS |
为什么需要 V8 沙箱
SANDBOX_PROCESS 使用 isolate 二进制文件，每次运行都会创建全新的 Linux 命名空间。这需要 CAP_SYS_ADMIN 权限——实际上需要设置容器的 privileged: true。V8 沙箱的存在就是为了让你无需授予此权限。
一个具体的 K8s 示例
你在自己的 Kubernetes 集群中运行 Activepieces，旁边还有一个 Salesforce 同步服务和一个财务分析 Pod。某个客户提交了一个恶意代码步骤。
- 使用
SANDBOX_PROCESS— Worker Pod 具有特权。内核漏洞逃逸到宿主机，读取服务账户令牌，访问 Kubernetes API，然后横向移动到 Salesforce Pod 和财务数据库。爆炸半径：整个集群。 - 使用
SANDBOX_CODE_ONLY— Worker 没有任何特殊权限。代码步骤在全新的 V8 隔离环境中运行（没有require、没有文件系统、没有 npm）。爆炸半径：仅限该 Worker Pod。
V8 隔离让你在不向工作流引擎授予内核级别访问权限的情况下，实现多租户代码安全。
各模式的工作原理
fork() + V8 — UNSANDBOXED、SANDBOX_CODE_ONLY
引擎作为普通的 child_process.fork 运行，并设置内存上限。在 SANDBOX_CODE_ONLY 模式下，每个代码步骤额外包装在全新的 isolated-vm 上下文中——每个隔离环境 128 MB，移除 require，步骤完成后释放。无需 Linux 命名空间机制、无需 CAP_SYS_ADMIN、无需特权容器。沙箱在作业之间保持热状态，执行速度很快。
- V8 保证： 用户代码无法访问
require、文件系统或其他步骤的内存。 - V8 不能： 如果宿主机 Node 进程本身被攻破，V8 无法保护隔离环境之间的安全性。
isolate 二进制文件 — SANDBOX_PROCESS、SANDBOX_CODE_AND_PROCESS
引擎在 ioi/isolate 中运行，每次运行都会创建全新的 PID、挂载、用户和 UTS 命名空间，并将引擎和代码产物以只读方式挂载。任意 npm 包在代码步骤中也是安全的，因为文件系统和进程状态都限定在隔离环境中。代价是每次运行需要冷启动（不可复用），并且 Worker 容器必须持有 CAP_SYS_ADMIN 权限——Docker 中为 --privileged，Kubernetes 中为 securityContext.privileged: true。
网络隔离
执行模式决定用户代码如何运行；AP_NETWORK_MODE 决定其可以访问什么。请参阅网络安全了解基于每种沙箱模式的 SSRF 防护、出口代理和 iptables 封锁。