Cube Sandbox

简体中文

English

简体中文

English

Appearance

什么是安全边界与隔离模型 ​

一句话定义 ​

CubeSandbox 的核心价值，不只是“把代码跑起来”，而是：

把不可信、不可预测、可能带有攻击性的工作负载，放进一个边界清晰、可控、可回收的执行环境里运行。

因此，安全边界与隔离模型不是附属主题，而是理解 CubeSandbox 的最后一块地基。

为什么必须先讲“边界”，再讲“安全” ​

很多系统谈安全时会直接列特性：

  • 独立内核
  • eBPF 网络隔离
  • API 鉴权
  • TLS
  • 权限控制

这些都重要，但如果不先问一个问题，就永远看不清：

CubeSandbox 试图保护谁，防谁，边界画在哪里？

安全从来不是抽象美德，而是边界管理。

理解 CubeSandbox 的安全，必须先回答三个问题：

  1. 哪些东西必须彼此隔离？
  2. 哪些东西必须可以被平台控制？
  3. 哪些风险不在这个系统单独兜底的范围内？

CubeSandbox 最核心的安全命题 ​

CubeSandbox 面对的典型场景是：

  • 用户代码不可信
  • Agent 行为不可完全预测
  • 工作负载可能主动发起网络访问
  • 实例可能运行复杂用户态程序甚至服务

因此它最核心的安全命题是：

如何让一个实例中的风险，不轻易溢出到宿主机、其它实例和整个平台。

这和普通“把服务部署起来”的平台诉求有本质不同。

CubeSandbox 的边界不是单一边界，而是多层边界 ​

把 CubeSandbox 的安全边界理解成一条线是错误的。它更像是多层叠加的边界模型。

1. 执行边界 ​

执行边界解决的是：

  • 实例里的进程是否与宿主机共享内核执行上下文
  • 一个实例里的崩溃或攻击是否会直接影响其它实例

CubeSandbox 选择以独立 Guest 内核和 MicroVM 作为这一层的核心基础。

2. 状态边界 ​

状态边界解决的是：

  • 一个实例的运行状态是否会污染另一个实例
  • 实例写入的数据是否会回写到模板母版
  • 回收后差异状态是否会残留

这层依赖模板 / 可写层 / 生命周期回收等机制共同成立。

3. 网络边界 ​

网络边界解决的是：

  • Sandbox 是否能随意访问内网与宿主机
  • 一个实例的网络行为是否天然暴露给另一个实例
  • 是否能按实例粒度控制出站与入站能力

这层由 CubeVS、节点本地网络编排、端口暴露与代理路由共同构成。

4. 平台控制边界 ​

平台控制边界解决的是：

  • 谁能创建实例
  • 谁能访问 API
  • 谁能暴露服务
  • 谁能修改模板与运行参数

这层更多落在控制面、鉴权、配置和运维治理之上。

为什么“独立 Guest 内核”是最关键的安全语义之一 ​

CubeSandbox 和普通共享宿主机内核容器模型最大的安全区别，往往就体现在这里。

共享内核模型的问题 ​

当多个不可信工作负载共享同一个宿主机内核时，平台必须假设：

  • 内核攻击面是共享的
  • 内核级漏洞一旦被利用，可能直接影响宿主机或其它租户
  • 隔离主要依赖 namespace / cgroup / seccomp 等防线组合

这套模型在很多场景有效，但面对“执行任意用户代码”的 Agent 场景时，压力会显著增大。

独立 Guest 内核带来的变化 ​

当每个 Sandbox 都运行在独立 Guest 内核里，风险面被重新切分：

  • 实例内部问题首先被限制在 Guest 边界内
  • 不同实例之间不再天然共享同一内核上下文
  • 平台对“容器逃逸即宿主失守”的担忧显著下降

这并不意味着安全问题消失，而是意味着：

最关键的一层隔离边界被前移到了更靠近实例的位置。

网络隔离为什么是安全模型的第二根支柱 ​

仅有运行边界还不够。

即便实例之间在执行上下文上隔离，如果网络上仍能彼此自由探测、横向访问宿主机或私网，那么平台整体风险仍然很高。

因此 CubeSandbox 的网络能力不只是“连接能力”，更是安全能力：

  • 默认阻断敏感地址空间访问
  • 按实例施加出站策略
  • 按平台元数据决定哪些入口可暴露
  • 通过节点网络平面实现细粒度隔离

对于不可信代码执行平台来说，这一点和独立 Guest 内核同等重要。

为什么 Template 与 Snapshot 也属于安全模型的一部分 ​

这听起来可能有点反直觉。

Template、Snapshot 往往被看成性能概念，但它们也影响安全边界。

Template 影响基础环境一致性 ​

如果模板边界不清晰，就容易出现：

  • 母版被实例污染
  • 不同实例起点不一致
  • 难以判断问题源于模板还是实例运行期

Snapshot 影响状态复用边界 ​

如果系统不能清楚地区分“可共享基础状态”和“实例私有差异状态”，就可能出现不应共享的状态被复用的问题。

所以：

  • 性能优化必须建立在严格边界之上
  • 快照复用不能以实例私有状态泄漏为代价

平台信任模型：谁被默认信任，谁不被默认信任 ​

理解安全边界时，必须明确系统的信任分层。

一般会被更高信任的部分 ​

  • 控制面组件
  • 节点宿主机与平台运维面
  • 经过治理的模板与平台配置
  • 平台入口与鉴权逻辑

不应被默认完全信任的部分 ​

  • Sandbox 内部执行的用户代码
  • Agent 生成的命令、脚本、下载内容
  • Guest 内部动态运行结果
  • Sandbox 对外部世界发起的网络行为

CubeSandbox 的整体设计，正是围绕这个信任分层来构建的。

“平台安全”不等于“用户代码安全” ​

这是另一个必须说透的点。

CubeSandbox 的目标是：

  • 限制不可信代码对平台和邻居的伤害范围
  • 给不可信代码提供受控执行空间

它不等于：

  • 自动审计所有用户代码逻辑是否安全
  • 自动阻止一切业务层漏洞
  • 自动保证 Guest 内应用本身没有漏洞

也就是说，CubeSandbox 提供的是 基础执行边界安全，而不是替代应用安全、供应链安全或业务安全本身。

安全边界内外各自承担什么责任 ​

平台侧责任 ​

平台通常要保证：

  • 实例边界足够强
  • 网络路径受控
  • 模板与实例状态分层清晰
  • API、配置和暴露入口有治理能力
  • 节点回收和清理不留下明显残留风险

使用方责任 ​

使用方仍然需要保证：

  • 选择合适模板
  • 配置合理的网络开放范围
  • 不把敏感密钥无节制地注入实例
  • 对业务级访问控制与代码来源做治理
  • 对 Guest 内应用本身的安全负责

安全永远是分层责任，而不是一键托管。

为什么“可回收”也是安全能力 ​

很多人把安全只理解成“防攻击”。

但对于高频创建销毁的平台，回收正确性 本身就是安全能力。

如果一个 Sandbox 销毁后：

  • 网络映射没释放
  • 可写状态没清干净
  • 本地临时目录残留
  • 元数据仍然可误引用

那边界就并没有真正结束。

因此回收不是运维附属动作，而是安全边界闭环的一部分。

常见误解 ​

误解一：有独立 Guest 内核就等于绝对安全 ​

不对。

独立 Guest 内核显著增强边界，但平台安全仍然依赖：

  • 节点配置
  • 网络策略
  • 控制面鉴权
  • 模板治理
  • 运行时实现质量

误解二：网络隔离只是“锦上添花” ​

不对。

对执行不可信代码的平台来说，网络往往是攻击面和数据外流面。没有网络边界，安全模型是不完整的。

误解三：Sandbox 里发生的事只要不逃逸，就与平台无关 ​

不对。

即使不发生宿主逃逸，实例内资源滥用、恶意出网、异常暴露服务、残留状态污染等，仍然会影响平台安全与治理。

你应该记住的核心判断 ​

如果只记一句话，请记住：

CubeSandbox 的安全不是单点能力，而是“独立 Guest 内核 + 分层状态模型 + 实例级网络控制 + 平台治理”的组合结果。

和相关文档的关系 ​

总结 ​

到这里，CubeSandbox 最核心的概念链条就完整了：

  • Sandbox 是交付对象
  • Template 是母版对象
  • MicroVM / Runtime / Guest 是运行模型
  • Snapshot 是性能复用机制
  • Node / Cluster / Scheduling 是平台扩展模型
  • Network / Exposure 是可达性与网络边界模型
  • Filesystem / Writable Layer 是状态分层模型
  • Security Boundary 是这些能力最终共同服务的目标

如果你已经理解这些概念，再去看快速开始、模板制作、运维手册或源码，视角会完全不同。