即时通讯后端【免费下载链接】WuKongIMMore than just IM 不只是即时通讯(IM)项目地址https://gitcode.com/gh_mirrors/wu/WuKongIM点击查看免费下载本文以 WuKongIM 仓库中的架构决策记录 ADR-0020Simulate only trusted main revisions 为主体结合.github/workflows下的真实工作流与scripts/cloud-sim脚本说明该决策的信任模型、Git 校验实现、无凭据构建与受保护环境审批如何共同把云仿真Cloud Simulation的计费资源创建限制在可信main历史内以及该策略在分析Analysis与修复Remediation环节的落地方式。一、决策背景为什么云仿真必须限制来源WuKongIM 的 Cloud Simulation 是一套在云端创建三节点集群 压测机sim host并运行真实工作负载的自动化体系。它会在阿里云上创建 ECS 实例、数据盘、弹性公网 IP 等计费资源还会把包含 Analysis MCP、诊断工具的服务端部署到这些主机上。如果任意分支、任意 fork 的 Pull Request 提交都能触发这套流程攻击者就能通过一次恶意提交让 CI 使用仓库级云凭据创建大量资源或者注入被篡改的工作流定义来窃取凭据。因此 ADR-0020 制定了第一版信任策略核心约束可以概括为Provisioning供应工作流只能从**默认分支main**发起接受的源码提交必须是可信main历史中的成员通过 Git 祖先关系验证构建 Job 不持有任何云凭据创建计费资源的供应 Job 由受保护环境protected environment审批门禁把关工作流定义、Analysis Skill、Analysis MCP 工具链一律来自可信main修复类 Draft PR 始终以当前main为目标任意分支与 fork PR 提交被排除在外直到另行设计并批准非可信来源模式untrusted-source mode。该 ADR 与 ADR-0036Deliver cloud simulation as verified tracer phases 描述的分阶段验证路径互为补充后者决定何时开放某个能力前者决定允许什么代码来源进入这条路径。二、信任的核心source_sha 必须属于可信 main 历史2.1 输入面默认分支 可选精确提交在 cloud-sim-provision.yml 中workflow_dispatch的输入定义直接体现了信任策略on: workflow_dispatch: inputs: source_sha: description: Optional exact commit reachable from trusted main; empty uses current main required: false default: type: string该工作流没有pull_request或push触发事件只能通过workflow_dispatch手动发起source_sha为空时使用当前main最新提交有值时必须是可从可信 main 到达的精确提交scripts/cloud-sim/setup.sh中同样固化这一前提它要求默认分支必须是main否则直接失败the current trust policy requires main to be the default branch并在引导完成后通过repos/$repository/commits/main解析可信main的 40 位 SHA 作为推荐输入。2.2 校验面一条完整的 Git 信任证明链供应工作流构建 Job 的第一步Prove source is a trusted main revision是信任策略的程序化落地逐条实现了属于可信 main 历史的定义git fetch --no-tags origin main source_sha$REQUESTED_SOURCE_SHA if [[ -z $source_sha ]]; then source_sha$(git rev-parse origin/main) fi [[ $source_sha ~ ^[0-9a-f]{40}$ ]] # 1. 必须是完整 40 位 SHA git cat-file -e ${source_sha}^{commit} # 2. 该对象必须是真实存在的 commit git merge-base --is-ancestor $source_sha origin/main # 3. 必须是 origin/main 的祖先 git checkout --detach $source_sha # 4. 检出到分离 HEAD test $(git rev-parse HEAD) $source_sha # 5. 确认检出的就是声明的提交这五个断言缺一不可断言防护目标40 位十六进制正则拒绝短 SHA、路径型引用或注入的 Git 参数cat-file -e存在性拒绝不存在的对象引用merge-base --is-ancestor拒绝不在main祖先链上的提交分支提交、已合入后又回滚的孤儿提交等--detach检出 rev-parse复核确保后续所有构建命令在被证明的源码上执行而不是在仓库默认 HEAD 上执行校验通过后SOURCE_SHA会写入GITHUB_ENV并作为 Job 输出传递给后续步骤同时被写入部署 bundle 的bundle-spec.json与运行时的analysis.envWK_ANALYSIS_SOURCE_SHA使整条链路构建 → 供应 → 分析都能追溯到同一个被信任的提交。同样的merge-base --is-ancestor祖先校验模式也复用在仓库的其他发布/部署工作流中如 cloud_deployment_bundle_workflow_test.go 中git -C source merge-base --is-ancestor $REQUESTED_SOURCE_SHA origin/main的断言说明祖先链信任是仓库级一致的安全惯例而非云仿真独有。三、凭据与责任分离无凭据构建 受保护环境供应信任策略的另一个关键设计是把构建和创建计费资源拆成两个 Job并施加完全不同的权限。3.1 build Job只读、无云凭据在 cloud-sim-provision.yml 顶部整个工作流的最小权限声明为permissions: contents: readbuild Job 内部只做三件事证明源码属于可信 main上文 2.2 的 Git 校验链构建静态 Go 二进制wukongim、wkcli、wkanalysis、wkcloudsim、wkcloudbundle、wkcloudhost、wkcloudgate等CGO_ENABLED0交叉编译使用wkcloudbundle render渲染并密封不可变部署包bundle连同bundle_digest、scenario_digest一起作为输出。它没有id-token: write也不访问任何secrets.ALIBABA_CLOUD_*因此即使某个被误接受的提交中包含恶意代码构建阶段也无凭据可窃取——它生产的是一个可校验摘要的静态产物而不是一个有权限的动作。3.2 provision Job受保护环境门禁 短期身份真正的计费动作集中在 provision Jobprovision: needs: build runs-on: ubuntu-24.04 environment: cloud-sim-provision # 受保护环境需人工审批 permissions: contents: read actions: write id-token: write受保护环境cloud-sim-provisionGitHub 允许为环境配置审批者workflow_dispatch触发后创建计费资源前需要经过环境审批。这是决策中protected-environment approval gates the provisioning job that creates billable resources的直接体现id-token: writeJob 通过 GitHub OIDC 换取短时、工作流条件限定的 STS 身份aliyun/configure-aliyun-credentials-action配合ALIBABA_CLOUD_SIM_PROVISIONER_ROLE_ARN等变量替代长期 AccessKey 存储在仓库中该 Job 还执行运行身份派生run_idgh-${GITHUB_RUN_ID}-${GITHUB_RUN_ATTEMPT}、创建精确运行资源wkcloudsim create、部署 bundle、执行 Bootstrap Gate 校验、开启公共观测、启动工作负载并落盘finalize.json调度清单等一系列动作。关于凭据模式ADR-0038Allow AccessKey onboarding with OIDC fallback 进一步说明仓库同时支持两种阿里云认证模式AccessKey 对作为 Repository Secrets仅在受保护的云 Job 内可用从不写入源码、制品、摘要、云主机或日志OIDC 仍是长期优选的加固路径因为它用短时工作流限定 STS 凭据替代了存储的长期凭据。无论哪种模式凭据都不会流经 build Job。四、端到端可信工作流定义、Analysis Skill 与 MCP 工具链ADR-0020 的信任承诺不止于供应环节还延伸到消费这些资源的一方——分析工作流。4.1 分析工作流固定在 main 上执行在 cloud-sim-analyze.yml 中jobs: prepare: runs-on: ubuntu-24.04 environment: cloud-sim-analysis permissions: contents: read actions: read id-token: write steps: - uses: actions/checkout... with: ref: main # 工作流定义与工具链永远来自 main persist-credentials: falsecheckout固定ref: main意味着执行分析的代码工作流定义、Analysis Skill、MCP 工具实现永远来自可信 main而不是来自某个可能被篡改的运行时分支。4.2 运行时契约也携带 main 引用供应阶段写入 sim 主机analysis.env的环境变量同样固化了信任边界WK_ANALYSIS_GITHUB_REFrefs/heads/main WK_ANALYSIS_GITHUB_WORKFLOW_REF$GITHUB_REPOSITORY/.github/workflows/cloud-sim-analyze.ymlrefs/heads/main WK_ANALYSIS_GITHUB_ENVIRONMENTcloud-sim-analysis这些变量与服务端契约测试见 runtime_contract_test.go 所覆盖的运行时契约配合确保部署到云上的分析端只知道来自 main 的仓库身份不会把任意分支当作合法来源。4.3 分析只针对存活的运行信任策略与 ADR-0003Analyze live Simulation Runs only 形成闭环分析工作流通过 Run Locator 精确解析运行cloud-sim-locator-${RUN_ID}制品要求run_id、source_sha、scenario_digest、region、account_id_hash全部通过格式校验并依据云端资源清单验证运行仍存活若运行已释放则记录释放证据并以失败状态终止避免缺失的分析被误认为成功。这里的source_sha正是供应阶段从可信 main 证明后写入 Run Locator 的同一个提交。五、修复 Draft PR 永远指向当前 mainADR-0020 还规定修复类 Draft PR 必须针对当前main。这意味着分析发现的问题即使被自动生成修复建议也不会把补丁开到一个中间分支上而是始终以最新可信 main 为基线避免基于过期 main 的修复引入漂移或冲突。结合 ADR-0036 的分阶段计划隔离的 Draft-PR 修复本身就是一个独立验证阶段只有本地契约、阿里云生命周期、实时分析依次证明稳定后才会启用仓库变更能力。六、排除面任意分支与 fork PR 提交第一版策略明确排除任意分支的提交fork Pull Request 的提交。只要这些来源的提交不满足可信 main 祖先这一几何条件就会在Prove source is a trusted main revision步骤被merge-base --is-ancestor拒绝工作流直接失败。仓库目前的 34 个云相关工作流均以workflow_dispatch为入口见 .github/workflows 目录没有为 PR 来源开放云供应入口与untrusted-source mode 需另行设计并批准的决策一致。七、实现与测试证据该策略不是停留在文档层面的声明而是被测试固化的行为契约cloud_sim_workflows_test.go 断言工作流输入source_sha的说明文案为 Optional exact commit reachable from trusted main; empty uses current main防止信任语义被无意改写setup.sh 强制默认分支为main、要求.github/workflows/cloud-sim-provision.yml等文件在远端 main 上存在、并在引导完成后输出一组推荐输入region、source_sha、scenariocloud-small、duration30m、max_total_cost70把可信 main 起点直接交到首次验证运行的启动者手中cloud-sim-provision.yml 的Prove source is a trusted main revision步骤是决策中每条规则的可执行实现。八、相关决策链路这篇 ADR 属于 WuKongIM 云仿真治理体系的一环与以下记录联动阅读更完整ADR-0003分析只针对存活的运行释放证据与失败语义ADR-0021工作负载时长与分析宽限分离运行租约整体参与成本估算ADR-0036按验证阶段逐步开放能力ADR-0038AccessKey 快速上云与 OIDC 长期加固的凭据模式其他如 ADR-0015成本与并发护栏、ADR-0030分析访问窗口共同构成只有可信代码、只有受控成本、只有有界时间的完整护栏。总结ADR-0020 回答的是谁有资格让 WuKongIM 在云端花钱运行仿真这一安全问题。它的答案是只有可证明属于可信main祖先链的提交只有只读、无凭据的构建只有受保护环境审批后的供应动作以及永远来自main的工作流与工具链。这套Git 祖先证明 权限最小化 环境门禁的组合使云仿真的每个计费动作都可以追溯到仓库中一个被明确信任的源码修订。赞分享即时通讯后端【免费下载链接】WuKongIMMore than just IM 不只是即时通讯(IM)项目地址https://gitcode.com/gh_mirrors/wu/WuKongIM点击查看免费下载相关推荐NemoClaw 受信任 main 分支 E2E 分发全流程运行模式、凭据边界与结果核验NemoClaw 受信任 main 分支 E2E 分发全流程运行模式、凭据边界与结果核验 本文基于仓库维护者技能 .agents/skills/nemoclaWuKongIM 云仿真分析边界只分析仍在运行的 Simulation Run 及其释放证据机制WuKongIM 云仿真分析边界只分析仍在运行的 Simulation Run 及其释放证据机制 导读 本文围绕 WuKongIM 仓库中的架构决策记录即时通讯后端5 分钟搭好 Sunshine 游戏串流免费的个人云游戏方案5 分钟搭好 Sunshine 游戏串流免费的个人云游戏方案 一个下午我把书房那台电脑变成了客厅的游戏机 周六晚上你窝在沙发上电视还停在开机画面。书房里音视频后端上一篇Note Companion API集成指南如何与其他工具无缝连接下一篇如何用Docker与Kubernetes实现STORM知识系统的容器化部署创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
