Show HN: Nucleus – 一个安全加固、原生支持 Nix 的容器运行时

背景

在当前的容器生态中，Docker 及其背后的 OCI（Open Container Initiative）标准占据了主导地位。然而，随着 AI Agent（智能体）工作负载的兴起以及对生产环境安全性、可复现性要求的提高，传统容器运行时逐渐显露出一些局限性。Docker 等工具通常依赖镜像注册表、分层文件系统以及命令式的部署脚本，这在某些场景下引入了不必要的复杂性、潜在的安全攻击面以及状态不可控的问题。

在此背景下，Nucleus 作为一个新兴的 Linux 容器运行时项目被提出。它并非旨在成为 Docker 的直接替代品，而是针对特定需求——特别是 AI Agent 的临时沙箱和需要严格隔离的生产服务——提供了一种极简主义、声明式且安全加固的替代方案。Nucleus 深度集成 Nix 生态系统，利用 Linux 内核原语（如 cgroups、namespaces 等）提供轻量级的隔离，同时消除了传统运行时常见的开销。

核心内容

Nucleus 是一个极简主义的 Linux 容器运行时，旨在为 AI Agent 和工作负载提供隔离的执行环境。它利用 Linux 内核原语构建隔离环境，避免了传统容器运行时（如 Docker 或 containerd）带来的额外开销。对于生产服务，Nucleus 采用完全声明式的模型：由 Nix 构建根文件系统（rootfs），NixOS 模块声明服务，而 Nucleus 在运行时挂载一个固定且可复现的闭包（closure）。

三种运行模式

Nucleus 支持三种主要操作模式，以适应不同的工作负载需求：

1. Agent 模式（默认）：专为 AI Agent 工作负载设计的临时、快速启动沙箱。
2. 严格 Agent 模式：针对不需要生产级根文件系统、健康检查、sd_notify 或 NixOS 服务语义的临时 Agent 工作负载，提供“故障关闭”（fail-closed）的隔离机制。
3. 生产模式：为长期运行、网络绑定的 NixOS 服务提供严格隔离。此模式包含声明式配置、可复现的 Nix 构建根文件系统、出口策略执行、健康检查以及 systemd 集成。

核心设计理念

Nucleus 的生产部署旨在实现以下目标：

• 完全声明式：服务拓扑、运行时设置和挂载的根文件系统均在部署前定义，而非在部署时通过命令式脚本组装。
• 原生 Nix 支持：提供一流的 NixOS 模块支持，以及 nucleus.lib.mkRootfs 用于构建最小化的服务闭包。
• 可复现性：基于 Flake 的构建、固定的存储路径（pinned store paths）以及根文件系统证明（rootfs attestation），确保运行时输入的稳定性和可审计性。

性能与基准测试

在原生运行时下，PostgreSQL 在 Nucleus 隔离下的性能接近裸金属（bare-metal）水平。基准测试在 Linux 6.18 x86_64 上进行，使用绑定挂载主机 pgdata 目录和 --network host 参数的原生运行时，以衡量 Nucleus 隔离的稳态成本，而非 VM 或 gVisor 模拟的开销。测试结果显示，在 SELECT-only（读密集）和 TPC-B（混合读写）场景下，Nucleus 的性能与裸金属相当，偶尔出现的性能优势应视为基准噪声，而非 guaranteed speedup（保证加速）。

关键特性详解

• 声明式默认配置：生产部署定义在 NixOS 和 TOML 文件中，而非通过临时的运行时脚本拼接。
• 深度 Nix 集成：包括一流的 NixOS 模块、mkRootfs 以及 Nix 存储闭包，用于构建最小化、锁定状态的服务根目录。
• 零开销隔离：直接使用 cgroups、namespaces、pivot_root、capabilities、seccomp 和 Landlock 等 Linux 内核机制。
• 内存支持的文件系统：容器磁盘映射到 tmpfs，并预填充 Agent 上下文。
• gVisor 集成：可选的应用程序内核（runsc）以增强安全性，支持网络服务模式。Nucleus 生成 OCI bundle/config 数据供 runsc 使用，包括进程身份、挂载点、namespaces、seccomp、hooks 和 cgroup 路径连接。
• 分离模式（Detached mode）：通过 --detach 将容器作为 systemd 瞬态服务在后台运行，并通过 nucleus stop、/logs、/attach 进行管理。
• 明确的工作负载身份：原生和 gVisor 运行时可以在特权设置后降级到配置的 uid/gid 及辅助组。
• 外部安全策略：支持每服务的 seccomp 配置文件（JSON）、能力策略（TOML）和 Landlock 规则（TOML），并带有 SHA-256 固定。
• Seccomp 配置文件生成：Trace 模式记录系统调用，随后 nucleus seccomp generate 创建最小化的白名单配置文件。
• 多容器拓扑：支持等效于 Docker Compose 的 TOML 格式，包含依赖 DAG、协调机制和 NixOS systemd 集成。
• 完整性与审计控制：提供结构化审计日志、机器可读的生命周期事件流、上下文哈希、根文件系统证明、seccomp 拒绝日志、挂载标志验证和内核锁定断言。
• 结构化遥测：可选的 OpenTelemetry 导出，用于容器生命周期追踪。

与 Docker 的关系

Nucleus 不是 Docker 的即插即用替代品，也不是 Docker 的严格子集。两者功能集有重叠，但各有侧重。Nucleus 的精神更接近于 runc 或 gVisor 的安全沙箱运行时，同时也具备轻量级的声明式单主机编排能力。它放弃了 Docker 的“镜像和分发”部分，以换取更深的隔离、策略控制和可复现性。

如果用户的思维模型是“运行我的镜像而不是 docker run”，那么 Nucleus 不适合：因为它没有镜像、没有注册表、也没有持久状态。如果目标是“运行不受信任或临时的工作负载，并获得更强、可审计的隔离”，那么 Nucleus 正是为此设计。

技术实现细节

Nucleus 利用以下 Linux 内核隔离原语：

• Namespaces：PID、mount、network、UTS、IPC、user、cgroup，以及可选的时间隔离。
• cgroups v2：资源限制（CPU、内存、PIDs、I/O）。
• pivot_root：文件系统隔离（在 Agent 模式中提供 chroot 回退）。
• Capabilities：默认丢弃所有能力，或通过 TOML 策略文件配置（不可逆）。
• seccomp：系统调用白名单过滤，支持每服务 JSON 配置文件和基于追踪的生成（不可逆）。
• Landlock：基于路径的文件系统访问控制，通过硬编码默认值或 TOML 策略文件实现（需要 Linux 5.13+）。
• gVisor：可选的应用程序内核（runsc），支持 none、bridge handoff 和显式 gvisor-host 网络模式。
• OCI bundle 生成：为 gVisor 生成 config.json 及 bundle 布局，包括 process.user、生命周期 hooks、seccomp、资源限制和 namespace 映射。
• PID 1 init：生产模式下的迷你 init 监督进程，用于僵尸进程回收和信号转发。
• 内存中秘密（In-memory secrets）：在 /run/secrets 处专用的 tmpfs，源缓冲区挥发性清零。
• 挂载审计：生产模式下对挂载标志的事后验证。

容器文件系统由 tmpfs 支持，在 Agent 模式中由上下文文件填充，在生产模式中从预构建的 Nix 根文件系统闭包挂载。这使得生产服务可以从声明式构建、可复现的根文件系统运行，