ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

OpenSandbox eBPF 网络隔离实战:完整指南教你构建内核级沙箱防护

OpenSandbox eBPF 网络隔离实战:完整指南教你构建内核级沙箱防护 OpenSandbox eBPF 网络隔离实战完整指南教你构建内核级沙箱防护【免费下载链接】OpenSandboxSecure, Fast, and Extensible Sandbox runtime for AI agents.项目地址: https://gitcode.com/GitHub_Trending/ope/OpenSandbox在 AI Agent 时代让大模型生成的代码直接运行是常见需求而OpenSandbox正是为此打造的开源 AI Agent 沙箱运行时Sandbox runtime for AI agents——它通过eBPF 内核级观测、出口流量管控egress 隔离与系统调用加固seccomp/Landlock构建纵深防御帮助你在几秒钟内创建可信的隔离执行环境。这篇文章带你用 4 个步骤搞清楚 OpenSandbox 的内核级沙箱防护是如何一步步构建起来的。为什么 AI Agent 沙箱需要内核级防护 ️AI Agent 生成的代码往往不可预测它可能偷偷 curl 内网其他沙箱、扫描集群 Pod IP、甚至尝试提权。传统防护如普通容器、用户态监控存在明显短板防护手段局限Kubernetes NetworkPolicy基于 Pod 标签选择器标签不可控、无法覆盖动态创建的未来沙箱且难以精确表达拒绝所有其他沙箱的边界应用层代理无法感知沙箱进程的真实connect行为绕过即失效普通审计日志用户态采样有间隙恶意代码可以隐藏自己的行为因此 OpenSandbox 把控制点下沉到内核出口侧用 egress sidecar 强制阻断内部用eBPF 观测直接挂钩内核事件做到看得见、拦得住。双层防线egress 出口隔离 eBPF 内核观测OpenSandbox 的网络隔离不是单点防护而是分层设计详见架构文档 docs/architecture/network-isolation.md第一层egress sidecar 强制出口管控每个沙箱内置 egress sidecar通过deny.always规则文件无条件拦截对集群内部 CIDRPod IP、Service ClusterIP的访问规则优先级高于用户策略且每分钟热加载生效。这样沙箱间的横向扫描和越权访问被直接掐断合法对外访问只能走 OpenSandbox Ingress 的鉴权入口。FQDN 维度的出口控制原理可参考 oseps/0001-fqdn-based-egress-control.md。第二层eBPF 观测内核事件 真正内核级的部分在 execd沙箱内的执行守护进程中。execd 遵循 OSEP-0018 成为沙箱的 init 进程并可加载一个独立的execd-ebpf构建变体在内核中挂载三个观测钩子exec 钩子挂在sched_process_exec追踪点记录沙箱内每次进程执行文件名、父进程 PIDconnect 钩子挂在inet_sock_set_state追踪点捕获每次 TCP 连接的目标 IP、端口、协议privilege 钩子通过 kprobe 挂钩commit_creds实时发现 UID/GID 变化与新增 capability提权行为核心设计亮点在 components/execd/pkg/ebpf/audit.gocgroup 精确圈定BPF 程序通过target_cgroup常量把观测范围锁定在当前沙箱的 cgroup其他沙箱的事件直接被丢弃天然实现多租户隔离逐层失败开放fail-open某个钩子在内核上加载失败时只降级degraded其余钩子继续审计绝不让观测层拖垮沙箱启动结构化审计输出事件经 ringbuf 传回用户态写成带稳定信封ts/event/sandbox_id/pid/comm的 JSONL 审计文件默认路径/var/log/opensandbox/ebpf-audit.jsonl自动轮转100MB × 3 份 × 保留 7 天配置模型定义在 components/execd/pkg/isolation/config.goBPF 侧程序源码见 components/execd/pkg/ebpf/prog/audit.bpf.c。4 步启用 eBPF 内核级防护第 1 步使用 execd-ebpf 构建变体默认镜像同时携带两个二进制静态版execd不含 eBPF 代码和execd-ebpfCGO cilium/ebpf 观测版。需要观测时显式运行execd-ebpf本地构建可用make build-ebpf。第 2 步确认内核与权限三要素eBPF 观测有三个硬性前提缺一不可前提要求内核Linux ≥ 5.10 且开启CONFIG_DEBUG_INFO_BTF存在/sys/kernel/btf/vmlinux权限容器持有CAP_BPFCAP_PERFMON运行时gVisor / Kata 下宿主内核不可挂载此层会报告unsupported并自动跳过第 3 步打开 [ebpf] 配置在隔离配置 TOML 中启用观测示例见 components/execd/configs/isolation.example.toml[ebpf] enabled true observe [exec, connect, privilege] audit_file /var/log/opensandbox/ebpf-audit.jsonlobserve可按需只保留部分事件类型配置入口与默认值说明见 docs/components/execd.md。第 4 步验证状态并消费审计日志通过GET /v1/isolated/capabilities检查 eBPF 层状态active全钩子生效、degraded部分钩子缺失、unsupported前提不满足。随后即可在沙箱 cgroup 内触发行为docker exec执行命令、发起连接观察 JSONL 中落下的审计记录例如一条 connect 事件{ts:2026-09-14T11:20:03Z,event:connect,sandbox_id:sb-001,pid:42,comm:curl,dst_ip:10.244.1.7,dst_port:8080,proto:tcp}一行日志就能回答谁pid/comm、在哪个沙箱sandbox_id、连了哪台内网机器——这正是横向移动检测的关键证据。CI 中的端到端验证脚本可参考 scripts/execd-ebpf-smoke.sh。常见坑位与最佳实践 不要期待 eBPF 阻断当前版本 eBPF 层定位是观测observation only阻断职责由 egress sidecar 与 seccomp 拒绝清单承担——seccomp 默认就封禁了bpf、mount、ptrace等约 30 个危险系统调用沙箱内的代码无法自己加载 BPF 程序来关监控gVisor/Kata 用户宿主任核不可 attach建议改用kata-qemu以获得等效隔离 egress sidecar 支持平台级默认隔离用deny.always封住集群内部 CIDR 作为安全基线配合allow.always精确放行合法跨沙箱通信比逐沙箱声明network_policy更稳妥对比见 docs/architecture/network-isolation.md审计留存审计文件默认只落盘在沙箱节点把 JSONL 转发到集中式日志/告警系统是运维侧职责接上 SIEM 后提权与横向连接事件即可实时告警延伸阅读execd 组件文档docs/components/execd.md沙箱 init 与安全加固设计oseps/0018-execd-as-sandbox-init.md网络隔离架构docs/architecture/network-isolation.mdeBPF 观测实现components/execd/pkg/ebpf/audit.go隔离配置示例components/execd/configs/isolation.example.tomlOpenSandbox 的这套出口强制隔离 内核事件观测 系统调用加固组合拳让 AI Agent 沙箱从跑得起来进化到管得放心。如果你也在构建 Agent 基础设施值得把它纳入技术选型清单。【免费下载链接】OpenSandboxSecure, Fast, and Extensible Sandbox runtime for AI agents.项目地址: https://gitcode.com/GitHub_Trending/ope/OpenSandbox创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表