ZMUKE 组织基线规则

制定: 2026-08-15. 修订: 2026-08-17 (所有者确认: 取消 account-per-org,

改为单账号 + 按域名/zone 区分组织; Account token 与 Zone token 分开;

8milex.com 不管理, mocalmax 在管 zone 为 mocalmax.cc). 本文定义整个组织体系最基础的规则.

所有后续建设以本文为准; 修改必须由所有者确认. 归属 zmuke-vault 仓库

(治理文档 + vault 引擎源码), 本地 ~/workspace/zmuke/zmuke-vault.

1. 组织模型

• ZMUKE 是上级组织. 操作机定位相同: 各有一份 ~/vault, 都能做配置与

vault run; 互不同步, 在哪台干活就在哪台录入. 大脑主机另外还跑 fleet

控制面和部分业务容器, 这不改变它与其他操作机同等的 vault 定位.

• slaunchx、mocalmax 是 ZMUKE 的下级组织. 未来新业务按同构接入.
• 基础设施 (大脑主机、fleet 控制面、vault 引擎、管理 Hub) 归 ZMUKE;

业务资产归各业务组织.

• 归属只以部署事实为准, 不得从命名推断. 域名、容器名、profile 名记录的

是历史; 判定归属前必须验证实际绑定.

2. 五个资源平面

每个组织 (含 ZMUKE 自身) 在五个平面各有一套资源, 开通新组织 = 把五行补齐:

3. 命名规则

4. 凭据铁律

1. 不允许缺省参数. 任何工具缺输入即拒绝执行, 不猜测; 具名 vault profile

注入的值算显式 (操作者在命令行点了名), 继承的 shell 环境不算.

1. 值只经隐藏终端录入. 不进聊天、argv、日志、仓库、环境文件.
2. 不跨业务域复用凭据. 同类服务各组织单独签发; profile 存进其组织的域.
3. Cloudflare 只用 Account API Token, 禁用 User API Token. User token 以

用户身份触达其可见的全部 zone. 管理 token 的 Zone Resources 必须是该组织

Specific zone, 不得 All zones.

1. 管理凭据与运行时凭据分离; 每个机器调用方单独发 token, 以便单独吊销.
2. Agent 边界: vault 命令必须显式 --business <目标业务域>; 跨业务域

读写需所有者逐次授权; Agent 不执行任何会打印环境变量的命令.

1. Global API Key 任何情况下不创建、不使用.

5. Cloudflare 账号结构与权限分配

单账号 + 每组织一张管理 token (2026-08-17, 取消 Account/Zone 分置):

只管理一个 Cloudflare 账号. 组织边界是 zone 集合. Tunnel / Access 在

Cloudflare 侧无法按 zone 切开, 再拆 Account token 与 Zone token 换不来

隔离, 只增加张数和误撤风险. 每组织发一张够用的管理 token, Zone

Resources 只含该组织 zone.

• 本账号服务 zmuke、slaunchx、mocalmax. mocalmax 在管 zone 是

mocalmax.cc. 8milex.com 不管理. 对照见

CLOUDFLARE_ZONES.md.

• 每个 zone 只归属一个组织.
• 成员: 所有者主邮箱是 Super Administrator. 其他人只给其所属组织

zone 的 domain-scoped roles. 自动化不使用成员身份.

• 每组织管理 token <组织>-edge-infra → cloudflare-<组织>-workspace-admin

(存该组织 vault 域):

- Account: Cloudflare Tunnel Edit + Access: Apps and Policies Edit

- Zone: Zone Read + DNS Edit + Zone WAF Edit

- Zone Resources = 该组织 Specific zone, 禁止 All zones

- 键: CLOUDFLARE_API_TOKEN, CLOUDFLARE_ACCOUNT_ID

- Zone ID 不入库, 用时 GET /zones?name=<根域名>

• CI / Pages 另开一张, 不要和管理 token 合并 (避免 Actions 拥有改

DNS/WAF/Tunnel 的能力):

<组织>-workers-deploy → cloudflare-<组织>-workers-deploy

只勾实际用到的 Workers / Pages / R2 / KV / D1. 不含 Tunnel/Access/DNS/WAF.

mocalmax 这张已在 Gitea secret 里, 不要重建、不要撤销.

• 运行时: per-tunnel cloudflare-<组织>-<服务>-tunnel;

per-caller cloudflare-<组织>-access-<调用方>

• Zero Trust 共用一个 team; Access 应用按 hostname 归属组织.
• Token 设 TTL, 记所有人/用途/到期日 (不记值).
• 接受: 管理 token 的 Tunnel/Access 权限是账号级的. 靠命名、vault 分域、

不把一张 token 写入其他组织的域来约束.

6. 边缘入口规则

1. origin 不开任何入站端口, 对外只经 Named Tunnel.
2. 上线顺序固定: Tunnel → origin 验证 → Access (默认拒绝 + MFA) → WAF →

DNS 最后发布. hostname 不得在准入生效前可解析.

1. 大脑主机对本机服务的管理操作走 loopback, 不依赖外部入口.
2. fleet 控制面保持零公网暴露; 将其发布到 Tunnel 属重大架构变更, 需单独决策.
3. connector 只持有 runtime token; 管理 profile 不得注入 connector.

7. 目标修订与剩余工作

原「三个组织各开账号 + zone 迁出」战役取消 (原 Phase A/C/D).

已完成且仍然有效:

• Phase B: zmuke 域 edge-infra token、Tunnel / Access / WAF、Gitea 入口

(事实与操作记录见 HANDOFF.md).

• Phase E 主体: zmuke Gitea 初始化、本仓库与引擎远端、SSH / Access 通道.

不再做:

• 用独立邮箱注册 SLAUNCHX / MOCALMAX 新账号.
• 把 slaunchx / mocalmax 的 zone 或 tunnel 迁到新账号.
• 把 8milex.com 迁入本账号, 或为它发 Cloudflare token.

还要做:

1. zone 对照已建 (CLOUDFLARE_ZONES.md); 所有者用

Dashboard 补全 slaunchx 未点名的 8 个 zone 名.

1. 按 CLOUDFLARE_SETUP.md 为每组织录入一张管理

token. 已有且仍在用的 *-workers-deploy (尤其 mocalmax Gitea Actions)

不要动.

1. vault-core P1 (DefaultPaths 回退链改为显式必填) 仍有效, 与本次修订独立.

8. 组织开通标准清单 (未来新业务)

1. fleet Workspace 创建, 节点入网走 workspace-bound enrollment.
2. 若该组织需要本账号托管的域名: 先写入

CLOUDFLARE_ZONES.md, 再发该组织的 zone token;

Account token 已在 zmuke, 不新建账号、不新建 Account 级 token.

Access 应用按 hostname 归属.

1. vault 业务域 init; 治理与引擎以本仓库为准.
2. Gitea 实例 + 域名 (按第 6 节入口规则发布).
3. 全部命名按第 3 节; 全部凭据按第 4 节.

操作员手册，不要公开传播。不含 Token / Account ID / Zone ID。HANDOFF 不在此站。