后端容器运行时安全云原生【免费下载链接】sandstormSandstorm is a self-hostable web productivity suite. Its implemented as a security-hardened web app package manager. | Actively sponsored by our friends at TestMu AI项目地址https://gitcode.com/gh_mirrors/sa/sandstorm点击查看免费下载Blackrock 是 Sandstorm 项目为托管服务与企业级部署设计的集群管理技术它让一整个数据中心内 2 到约 2^16 台同地协作的机器或虚拟机实例对外呈现为一个Sandstorm 实例用户界面与单机版几乎无差别。本文以 roadmap/blackrock/README.md 为骨架结合仓库内src/sandstorm/与shell/下的真实实现系统讲解 Blackrock 的设计目标、七大机器角色、基于 Capn Proto 的自定义网络协议与 SturdyRef 持久化能力模型并逐条标注哪些设计已实现、哪些仍停留在路线图阶段帮助读者完整理解 Sandstorm 从单机走向横向扩展集群的演进思路。Blackrock 在 Sandstorm 生态中的定位在 roadmap/README.md 中Blackrock 被明确定义为 the cluster management technology underlying managed hosting and our eventual enterprise product托管服务与企业级产品底层的集群管理技术。也就是说它是 Sandstorm 平台三大技术方向之一与平台核心功能Platform、自托管体验Self-hosting并列。从运维视角看Sandstorm 默认架构是单机部署docs/administering/hosting-provider.md 明确指出 Sandstorm runs on a single server, due to its architecture单机模式下提升用户数的主要手段是纵向扩容内存RAM is the primary bottleneck。而当托管商需要服务成千上万用户时就需要横向扩展方案——Sandstorm.io 团队运营的 oasis.sandstorm.io 正是使用代号 Blackrock 的这套 scale-out 软件栈。该文档同时提醒Blackrock 远不如标准 Sandstorm 开箱即用far less turn-key托管商若采用它通常需要与 Sandstorm 开发者紧密协作并自行编写额外代码更好的路径是先跑单机需要时再迁移到 Blackrock。Blackrock 的设计目标Goals完整列举如下将 2 到约 2^16 台同地协作的机器或 VM 实例视为一个Sandstorm 实例用户界面与单机 Sandstorm 基本一致强制实施按用户或许还按应用的存储空间与内存配额支持机器动态加入或移出集群机器角色由集群自动分配并随需更新任何一台机器宕机都不造成用户中断或数据丢失在机器之间迁移 grains沙箱化应用实例以平衡负载、优化资源共享例如共享应用二进制文件通过避免可疑应用与高价值目标同机部署、监控主机可疑行为、定期清空并重启单台机器缓解沙箱逃逸风险在可用时利用廉价的对象存储。同时文档明确划定了非目标不支持地理位置分散的机器组成单实例——Blackrock 针对的是同一数据中心、同一 LAN 内的机器跨集群移动应用应使用 Sandstorm 常规的联邦federation能力。机器角色体系同一镜像、多角色分配Blackrock 集群中的所有机器都启动同一份只读操作系统镜像镜像内包含全部 Blackrock 平台软件机器启动后由集群主控master为其分配一个或多个角色。这种统一镜像 动态角色的设计直接支撑了机器动态加入/移出、角色自动调整的目标——没有角色固化在镜像里一切以运行时分配为准。整个角色体系分为八类Master主控、Storage存储、Workers工作机、Coordinators协调器TODO、Shells又名 Front-ends前端、Mongo数据库、Gateways网关、Log sink日志汇聚TODO。Master集群的角色分配与拓扑中枢每个集群有且仅有一台 master。其职责包括为所有其他机器分配角色监控全集群资源使用情况动态决策资源分配去向当机器规格异构时依据硬件特性分配合适角色——例如内存巨大的机器应做 worker磁盘巨大的机器应做 storage负责向所有其他机器通报应该与哪些对端通信的拓扑信息——例如新增一台存储节点后master 会更新所有可能用到存储的机器使它们把新节点加入各自的负载均衡池。关键可靠性设计是master 不在任何单次请求的服务关键路径上。若 master 宕机集群其余部分可以按照最近一次分配的角色继续运行等待 master 恢复。这与单台机器死亡不造成用户中断的目标直接呼应。Storage对象存储之上的能力化加密代理存储节点对外提供所有持久化存储的接口。文档特别强调术语区分存储节点storage node通常并不直接操作磁盘而是充当某个传统对象存储系统如 S3的代理真正的物理存储应称为disks磁盘。引入这层代理而非让其他机器直连磁盘目的有三实现基于 Capn Proto 持久化层的能力化capability-based对象图存储接口——存储的不是扁平文件而是相互引用、可沿对象图遍历的能力对象实现逐对象加密每个对象拥有独立加密密钥这些密钥本身作为访问对象所需的 SturdyRef 的一部分保存。由于 SturdyRef 通常又存储在其它已加密的对象中因此不沿对象图从用户持有的某个基础能力出发就无法访问任何对象。理论上这些基础能力甚至可以用用户的 GPG 密钥加密保存实现完美加密存储保护访问磁盘所需的凭据如 S3 凭据使磁盘端无需被信任即可保证隐私。文档给出的候选后端disk 层包括Amazon S3、Google Cloud Storage、Tahoe-LAFS以及一种利用本地集群所有磁盘的分布式文件系统。文档还保留了项目自注的 TODO截至文档记录时当前存储实现仍是单机写本地磁盘依赖底层磁盘实现提供完整性、可靠性与备份Oasis 托管在 Google Compute Engine利用其持久磁盘与快照能力单机存储层之所以能扛住大量负载是因为其工作基本只是读写块。但存储层应该被重写以支持更好的可扩展性并在可用时利用廉价对象存储。Workers运行 grain 的可疑机器与 nbd 块设备worker 机器按照协调器coordinator见下文的指令运行 grains。由于存在沙箱逃逸的可能worker 机器应始终被怀疑对待整个 Blackrock 集群使用 Capn Proto 能力安全模型保证一台被攻破的 worker 无法访问除恰好运行在它上面的 grains 之外的任何东西worker 应定期轮换出勤、清空wipe防止恶意进程长期驻留worker 还应接受统计意义上的可疑活动监控一旦发现立即移出轮换。worker 的关键存储机制是每个 grain 的存储通过nbdNetwork Block Device驱动挂载自一个用户态实现的块设备该用户态守护进程把块同步回存储层。这套设计带来两个直接收益数据量大的 grain例如音乐库可以从冷状态快速启动——按需on-demand拉取块即可长期存储可以保持接近最新状态从而让 worker 机器故障不至于造成过多数据丢失。与此同时内核在块设备之上实现了久经考验的缓存层页面一旦缓存就能把运行时开销降到最低。文档还留下一个 TODO(feature)可以探索优化初始加载时间的启发式策略例如跟踪启动时常加载的块并提前开始读取并且 nbd 实现了 trim 命令可以用来跟踪文件系统实际使用的块、避免存储无用数据。CoordinatorsTODO(feature)尚未实现的调度层截至文档记录2017 年 2 月协调器尚未实现——Currently frontends simply round-robin to workers当前前端只是对 worker 做轮询。文档中的协调器设计如下协调器告诉 worker 做什么要启动新 grain 或启动一个当前未运行的 grain必须先联系协调器由它挑选合适的 worker 委派任务每个协调器维护一组 worker这些集合可以重叠也可以不重叠——可以是两个协调器各监控全部 worker也可以各监控一半启动 grain 的请求可交给任意协调器调用方应在它们之间做负载均衡协调器监控其 worker 上的资源使用并在需要时下达 grain 迁移指令它应当考虑每个应用的典型资源占用以及该应用的可疑程度——可疑应用应与安全关键型应用隔离以缓解沙箱逃逸的影响。文档评价该模块有大量算法与启发式策略的开发空间属于路线图中留白最多的领域。Shells又名 Front-endsMeteor 前端Shell 机器运行 Sandstorm shell UI——一个 Meteor 应用。代码中这些机器被称为 frontends前端文档认为这个叫法其实并不准确an arguably incorrect name。在仓库中shell/目录正是这套 Meteor 应用其服务端入口位于 shell/server/main.ts客户端入口在 shell/client/main.ts而 Blackrock 多副本场景下的能力路由基础设施可见于 shell/imports/server/frontend-ref.js 与 shell/imports/server/core.js。后者实现了FrontendRefRegistry前端能力引用注册表并围绕frontendRef字段把前端提供的 Capn Proto 能力保存为可恢复的持久引用——例如 core.js 通过globalFrontendRefRegistry.restore(db, saveTemplate, token.frontendRef)恢复能力这正是多 shell 副本场景下路由能力所依赖的机制。另外 shell/imports/server/accounts/saml/saml-server.js 中还有一条注释提醒某些状态可能需要在 Blackrock 下改用 Mongo collection 才能在多前端场景工作。Mongo当前依赖与长期替换计划由于 Sandstorm shell 当前依赖 Mongo 作为数据库Blackrock 集群需要专门的 Mongo 机器运行该数据库其中一台为主master、其余为从slave。文档列出两项 TODOTODO(feature)数据库也应同步回对象存储TODO(project)长期来看应当用自有存储接口替换 Mongo。这条依赖在仓库中同样可证shell/imports/server/core.js 有一段注释专门处理 Fix Mongo converting Buffers to Uint8Arrays说明 shell 与 Mongo 的数据交互是实打实的当前实现细节。Gateways连接公网与集群内部的桥网关gateway负责桥接公网或 Sandstorm 集群之外的更广企业网络工作拆分为几块接收入站 HTTP 请求、终结 SSL、转发给 shell 或直接转发给 grains——这是已实现的核心职责TODO(feature)实现一套 Capn Proto 接口用于对外建立/接受 TCP 连接以及参与 UDP 流量这类连接将被禁止连到集群内其他机器能力可交给设备驱动从而在不授予任何内网访问权限的情况下授予其外部网络访问TODO(feature)把 Capn Proto 本身代理到外部世界——内部网络与公网使用不同参数化的 Capn Proto 协议因此能力跨越边界时必须被主动代理这同时也让系统有机会把外部能力与内部能力分开追踪并向外部隐藏内部 SturdyRef 表示作为额外一层安全。仓库中网关的实现证据非常充分src/sandstorm/gateway.c 中的GatewayService是直接处理 HTTP 等流量的 C 代码而路由决策通过 src/sandstorm/backend.capnp 定义的GatewayRouter接口回到 Sandstorm 业务逻辑Node.js 进程网关先连接 backend 获得作为引导能力的GatewayRouter再通过openUiSession根据 sandstorm-sid cookie 换取 WebSession、openApiSession根据 Authorization 头中的 token 换取 ApiSession等方法完成会话路由。backend.capnp中还明确注释了 Blackrock 场景in Blackrock, where multiple instances of the shell might be running, all GatewayRouters are equivalent, regardless of which shell replica在 Blackrock 中即使运行多个 shell 副本所有 GatewayRouter 也都等价无论连到哪个副本——这是网关层与多副本 shell 解耦的直接依据。此外 src/sandstorm/config.c 中有一条配置日志 Gateway is no longer experimental. Disabling EXPERIMENTAL_GATEWAY is ...说明网关模块已经走出实验阶段。Log sinkTODO(feature)尚未实现的日志汇聚所有其他机器应向日志汇聚节点log sink汇聚日志以供分析。截至文档记录该功能尚未实现——Currently logs are collected and written to disk on the master machine当前日志由 master 机器收集并写到本地磁盘。网络与 Capn Proto 设计面向 LAN 的自定义协议Blackrock 集群使用一套为特定用例定制参数化的 Capn Proto RPC 协议。文档先给出实现现状注记截至 2017 年 2 月Capn Proto 仍运行在 TCP 之上且由于 3-party handoff三方交接尚未实现所有通信实际上都经 master 机器代理转发——这显然会在规模增长时成为瓶颈但当时运行平稳。传输层TransportUDP 优于 TCP 的理由Blackrock 假设内部通信是近乎全连通的网状fully-connected mesh——几乎每台机器都会向其他每台机器偶发发消息。既然假定在同一 LAN 内可以为此优化使用UDP 而非 TCP丢包在 LAN 中很罕见UDP 可以避免每次想跟一台尚未建立连接的机器通信都要做 TCP 握手该模型对临时网络抖动更鲁棒对 Capn Proto 软件来说断连相当有破坏性因为所有未持久化的能力都会丢失而基于 UDP 可以轻松设计等待网络恢复一段时间的策略。加密Cryptovat ID 与免握手的密钥交换每个 vat能力网络中的对等体/机器由唯一的vat ID标识。vat ID 实际上就是该 vat 自己生成的ed25519 公钥——对应的私钥绝不应离开生成它的机器且每当整机被清空时应一并丢弃。vat 可以通过对 challenge 签名来证明自己拥有某个 vat ID。在多数情况下Blackrock 实例的内部网络可能不需要分组加密因为高端网络硬件通常可被信任为只把包投递给正确目的地。但如果需要加密最直接的方式是curve25519 密钥交换两个 vat 仅凭彼此知道对方的 vat ID以及各自的私钥就能协商出共享秘密从而无需任何握手即可开始互发流量——这与 UDP 传输的设计天然契合。持久能力SturdyRefs能力网络的持久化基石在 Blackrock 网络内SturdyRef持久能力引用分为有限几种类型Storage refs直接指向存储中的对象由存储节点恢复restoreGrain refs指向特定 grain 内托管的 capability由协调器恢复External refs指向公网上的 capability由网关恢复Ephemeral refs指向某个特定 vat 上托管的 capability只能由该 vat 恢复这类 cap 天生短命因为 vat 本身短命频繁轮换但它们能挺过重启与进程崩溃比 live refs 更稳固。每个 SturdyRef 都被密封sealed到请求创建它的 vat 所属的trust zone信任区域并且只能由同一 trust zone 恢复——这防止了跨信任边界泄漏的比特bits被利用。每个 vat 自身是一个 trust zone此外还有四个特殊区域storage、gateways、coordinators、shells。这四个分组内的 vat 都能保存 SturdyRef使组内任意其他成员之后可以恢复它们。SturdyRef 在仓库源码中有大量印证。在 src/sandstorm/supervisor.capnp 中注释了 In the Sandstorm internal realm, the type of SturdyRefs themselves is simplyData并多处描述save()与restore()语义src/sandstorm/supervisor.c 中实现了把 token 设为 SturdyRef如setSturdyRef(args.getToken())、按SystemPersistent语义保存/恢复能力含sealFor信任区域逻辑等关键路径src/sandstorm/sandstorm-http-bridge.c 中也能看到应用侧尚未落盘、需要保存一个 SturdyRef的注释。在 src/sandstorm/grain.capnp 中则详细对比了授权码authorization code与 SturdyRef 的区别并解释为何避免让应用直接拿到新铸造的 SturdyRef——因为 SturdyRef 泄漏更危险攻击者可能拿它发起伪造的 powerbox 请求。这些注释共同表明SturdyRef 不是简单的对象 ID而是密码学安全、按信任区域密封的持久能力凭证这正是 Blackrock 对象图存储与 worker 不可信假设的安全基石。从路线图到现状实现状态总览原文档以 TODO 标注的形式记录了各模块的实现进度。下表汇总各角色/功能的文档标注状态与仓库中的佐证位置方便读者对照模块文档标注状态仓库佐证Master已设计每集群单台不在请求关键路径见本文第 3 节Storage已实现为单机本地磁盘重写为对象存储代理属 TODOsrc/sandstorm/backend.capnp配额/存储接口Workers已实现nbd 块设备 用户态同步守护进程src/sandstorm/沙箱与桥接代码Coordinators未实现前端轮询 worker无对应实现Shells/Front-ends已实现Meteor 应用shell/client/main.ts、shell/imports/server/frontend-ref.jsMongo已实现一主多从替换为自有存储属 TODO(project)shell/imports/server/core.jsGatewaysHTTP/SSL 终结已实现TCP/UDP 接口与 Capn Proto 外部代理属 TODO(feature)src/sandstorm/gateway.c、src/sandstorm/backend.capnpLog sink未实现日志暂写 master 磁盘无对应实现传输层未实现当前 Capn Proto 走 TCP经 master 代理无 UDP 实现加密设计完成ed25519 vat ID curve25519 协商文档为唯一来源SturdyRefs已实现save/restore、trust zone 密封src/sandstorm/supervisor.c、src/sandstorm/supervisor.capnp、src/sandstorm/grain.capnp需要强调的是roadmap/blackrock/README.md本身是技术路线图文档而非实现说明其中 Coordinators、Log sink、UDP 传输、外部 TCP/UDP 能力、Capn Proto 外部代理等条目均明确标注为 TODO读者不应将之当作当前可用功能。而 Storage 的对象存储代理 逐对象加密、SturdyRef 的 trust zone 模型等则在src/sandstorm/的 Capn Proto 模式与 C 实现中留下了可追溯的设计证据是理解 Sandstorm 能力安全模型从单机延伸到集群的关键。延伸阅读roadmap/blackrock/README.md本文核心来源——Blackrock 完整路线图原文roadmap/README.mdSandstorm 整体技术路线图说明 Blackrock 与 Platform、Self-hosting 的关系及 TODO 分类约定project / feature / roadmapdocs/administering/hosting-provider.md托管商视角的 Blackrock 定位与部署建议单机起步、需要时迁移src/sandstorm/backend.capnpGatewayRouter接口定义及 Blackrock 多 shell 副本等价性注释src/sandstorm/supervisor.capnp 与 src/sandstorm/grain.capnpSturdyRef 语义与授权码/持久能力对比的权威注释shell/imports/server/core.js 与 shell/imports/server/frontend-ref.js前端能力引用注册表与 Mongo 依赖的实际代码。赞分享后端容器运行时安全云原生【免费下载链接】sandstormSandstorm is a self-hostable web productivity suite. Its implemented as a security-hardened web app package manager. | Actively sponsored by our friends at TestMu AI项目地址https://gitcode.com/gh_mirrors/sa/sandstorm点击查看免费下载相关推荐Sandstorm 技术路线图全景解读平台功能、Blackrock 集群与自托管生态Sandstorm 技术路线图全景解读平台功能、Blackrock 集群与自托管生态 Sandstorm 是一个可自托管的 Web 生产力套件本质上是安全后端容器运行时安全云原生Sandstorm 平台功能路线图全解账户、应用、谷物与能力安全架构Sandstorm 平台功能路线图全解账户、应用、谷物与能力安全架构 本文以 Sandstorm 官方技术路线图 roadmap/platform/READM后端容器运行时安全云原生Sandstorm 平台级跨 Grain 全文搜索从安全索引架构到 Lucene/Lucy 实现路线Sandstorm 平台级跨 Grain 全文搜索从安全索引架构到 Lucene/Lucy 实现路线 Sandstorm 是一个以安全隔离为核心的自托管 We后端容器运行时安全云原生上一篇Open edX Platform MFE 配置端点治理ADR 0035 确立 /api/frontend_site_config/v1/ 为规范端点下一篇企业法务智能化的架构革新从模型选型到能力沉淀的范式重构创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考