1. 项目背景前十章几乎都在默认 VHostpromo里打转。安全评审一句话把现场冻结订单队列、营销 Fanout、运维 Tracing 共用一个命名空间任何一个「开发自测账号」都能 Purge 支付队列。上周营销同学用 UI 清堆积点错了q.order.pay对账差出 800 单。事故报告写的是「手滑」根因是没有户口隔离。不拆 VHost 的现实是promo一个大食堂 ├─ 订单交换机/队列 ├─ 营销广播 ├─ 日志 Topic └─ 所有人 administrator ↓ 一次 Purge / 一次错误绑定 / 一次 guest 远程 三个事业部同时中招权限其实有两套闸门第 5 章只讲了管理标签administrator / monitoring / management。本章补上AMQP 三正则configure声明/删改、write发布/绑定写入、read消费/get。标签决定能不能进 15672 的哪些菜单三正则决定 5672 上能对哪些对象动手。两套都是 administrator 的账号等于把钥匙焊死在大门上。guest 默认只能 loopback 登录。有人在 compose 里写了loopback_users.guest false第 3 章已警告这是放宽生产出现过从办公网用 guest 扫队列。本章实验明确删除 guest 远程可能另建应用用户应用用户不要管理标签。连接追踪也是户口的一部分出了事要知道是哪个用户、哪个 VHost、多少 Channel。不会list_connections的值班只能重启节点。约束仍是单机不引入 LDAP/OAuth2第 25 章。先把内部账号模型做对。2. 项目设计小胖把小区门禁卡往桌上一甩。小胖这不就是门禁吗刷卡进门。为啥还要三个小区、三种卡、卡上还印正则表达式食堂窗口认脸就行没听说炒菜还要匹配^q\\.order\\.。大师门禁只解决「你是不是本公司的人」。VHost 是三栋楼订单楼、营销楼、运维楼钥匙不能互开储藏室。正则是楼层权限应用只能碰自己前缀的队列不能.*配到删库跑路。食堂认脸适合十人团队三百人中台必须分楼。技术映射用户认证 进大门VHost 授权 进哪栋楼configure/write/read 在楼里能声明、能发、能收。小白三个 VHost 是三套完全独立的交换机名吗同名队列会不会冲突删 VHost 会怎样权限正则是匹配完整资源名还是带 VHost 的 URItopic permission 和普通 permission 什么关系用户标签与 AMQP 权限谁优先生效连接追踪存在哪节点重启会丢吗应用账号能不能完全不要 tag大师每个 VHost 是独立命名空间两边都可以有ex.order.direct互不可见这正是隔离的意义。删 VHost 会删掉其中所有对象和消息生产要开删除保护enable_protection_from_deletion。正则匹配的是资源名本身队列名/交换机名不是vhost/queue拼串。topic permission 额外限制Routing Key给日志 Topic 用普通 permission 管对象。两套闸门是与没进管理面不等于 AMQP 不能连有 monitoring 标签也可以 AMQP 权限为零。连接追踪在节点内存/追踪表重启会丢历史所以要靠日志与监控外送。应用账号应当无 tag只走 5672。小胖那运维看堆积怎么办总不能让他们也申请支付写权限。大师opsVHost 放 Tracing、备忘队列值班用 monitoring 看各 VHost 的只读统计标签允许看全局 Overview但 AMQP 仍按正则。需要 Get 消息时用单独的ops_read且只授 read禁止 write/configure。绝对不要为了「方便值班」把 administrator 发给个人域账号。技术映射monitoring 标签 ≠ write 权限看 UI 可以Purge 不行。小白set_permissions三个参数顺序记错会怎样空正则^$是拒绝一切还是允许空名权限变更对已建立的 Channel 立刻生效吗还有 loopback_users 和 TLS 客户端证书用户怎么配合大师顺序是 configure、write、read写反是最常见事故以为只能读实际能删。^$只匹配空字符串对正常队列名等于禁止该项。权限缓存存在连接/通道上变更后已有连接可能仍用旧缓存一小段时间测试应重连再验。证书用户第 25 章再讲今天内部口令用户足够。guest 继续只准本机容器互联一律自建用户。小胖实验就三栋楼、四类人订单应用、营销应用、值班只读、管理员。错楼、错正则必须 ACCESS_REFUSED不能 200。大师再加一枪用订单账号去 marketing 声明队列必须失败。这比任何规范 PDF 都硬。3. 项目实战3.1 环境准备容器rabbit-promo-1管理员暂用第 1 章的promo仅本实验引导。完成后应用不再用它连业务。pikacurl。3.2 步骤一三栋楼与四类人步骤目标创建 VHost 与用户权限写成可评审的正则。# promo-mq/ch11/provision.shset-eCdocker exec rabbit-promo-1$Crabbitmqctl add_vhost order$Crabbitmqctl add_vhost marketing$Crabbitmqctl add_vhost ops$Crabbitmqctl add_user app_orderord_dev_2026$Crabbitmqctl add_user app_mktmkt_dev_2026$Crabbitmqctl add_user ops_watchwatch_dev_2026$Crabbitmqctl add_user ops_adminadm_dev_2026$Crabbitmqctl set_user_tags app_order$Crabbitmqctl set_user_tags app_mkt$Crabbitmqctl set_user_tags ops_watch monitoring$Crabbitmqctl set_user_tags ops_admin administrator# configure/write/read$Crabbitmqctl set_permissions-porder app_order\^ex\.order\.|^q\.order\.^ex\.order\.|^q\.order\.^ex\.order\.|^q\.order\.$Crabbitmqctl set_permissions-pmarketing app_mkt\^ex\.mkt\.|^q\.mkt\.^ex\.mkt\.|^q\.mkt\.^ex\.mkt\.|^q\.mkt\.$Crabbitmqctl set_permissions-porder ops_watch^$^$.*$Crabbitmqctl set_permissions-pmarketing ops_watch^$^$.*$Crabbitmqctl set_permissions-pops ops_watch^$^$.*$Crabbitmqctl set_permissions-porder ops_admin.*.*.*$Crabbitmqctl set_permissions-pmarketing ops_admin.*.*.*$Crabbitmqctl set_permissions-pops ops_admin.*.*.*$Crabbitmqctl list_permissions-porder$Crabbitmqctl list_user_permissions app_order运行结果list_permissions里app_order三列正则均为订单前缀ops_watchconfigure/write 为^$。坑set_user_tags无参数表示清空标签应用账号必须这样。坑用户对某 VHost 完全没有set_permissions时连该 VHost 会直接拒绝不必等到 declare。坑PowerShell 里单引号与正则转义不同建议 Git Bash 跑脚本。源码上 VHost 是一等公民删除会动存储目录-export([add/2, add/3, add/4, delete/2, delete_ignoring_protection/2, exists/1, assert/1,鉴权入口在rabbit_access_control先用户口令再check_vhost_access再资源级check_resource_access。-export([check_user_pass_login/2, check_user_login/2, check_user_login/3, check_user_loopback/2, check_vhost_access/4, check_resource_access/4, check_topic_access/4,3.3 步骤二订单应用能声明越权必须失败步骤目标正向声明成功跨 VHost、跨前缀ACCESS_REFUSED。# promo-mq/ch11/acl_lab.pyimportpikafrompika.exceptionsimportProbableAccessDeniedError,ChannelClosedByBrokerdefconn(user,pwd,vh):returnpika.BlockingConnection(pika.ConnectionParameters(127.0.0.1,5672,vh,pika.PlainCredentials(user,pwd),client_properties{connection_name:fch11-{user}-{vh}}))# 正向cconn(app_order,ord_dev_2026,order)chc.channel()ch.exchange_declare(ex.order.direct,direct,durableTrue)ch.queue_declare(q.order.pay,durableTrue)ch.queue_bind(q.order.pay,ex.order.direct,pay.ok)print(order app: declare OK)c.close()# 跨 VHosttry:conn(app_order,ord_dev_2026,marketing)print(UNEXPECTED: crossed vhost)exceptExceptionase:print(cross vhost refused:,type(e).__name__,str(e)[:120])# 同 VHost 错误前缀cconn(app_order,ord_dev_2026,order)chc.channel()try:ch.queue_declare(q.mkt.sms,durableTrue)print(UNEXPECTED prefix)exceptChannelClosedByBrokerase:print(bad prefix:,e.reply_code,e.reply_text[:160])c.close()运行结果第一段成功跨 VHost 在建连阶段失败ProbableAccessDeniedError或连接关闭错误前缀 403 ACCESS_REFUSED通道关闭连接往往还在第 4 章隔离。坑回复码 403 与 HTTP API 403 不是同一条路径但验收都当「拒绝」。坑已有连接缓存旧权限时改完正则请重连再测。3.4 步骤三值班只读不能 Purgecurl-s-o/tmp/w-w%{http_code}-uops_watch:watch_dev_2026\-XDELETEhttp://127.0.0.1:15672/api/queues/order/q.order.pay/contentsechocat/tmp/w运行结果4xx队列仍在。ops_admin能进 UI 管理三栋楼但生产变更仍走工单不能日常用个人管理员点 Purge。坑标签 monitoring 仍可能看见多 VHost 统计这是设计如此危险操作靠 AMQP 权限与 UI 操作审计不要靠「看不见」。3.5 步骤四看见连接属于谁用订单账号保持连接 30 秒另开终端dockerexecrabbit-promo-1 rabbitmqctl list_connections name user vhostdockerexecrabbit-promo-1 rabbitmqctl list_channels connection numberdockerexecrabbit-promo-1 rabbitmqctl list_consumers-porder运行结果userapp_ordervhostorder。事故时先看这两张表再决定踢连接dockerexecrabbit-promo-1 rabbitmqctl close_all_user_connections app_orderch11-lab坑踢连接会让未 Ack 回流第 9 章先通知开发。3.6 完整代码清单column/samples/ch11/provision.sh column/samples/ch11/acl_lab.py3.7 测试验证编号操作期望TC-CH11-01app_order 声明订单对象成功TC-CH11-02app_order 连 marketing拒绝TC-CH11-03app_order 声明 q.mkt.*403TC-CH11-04ops_watch Purge4xxTC-CH11-05list_connections 含 user/vhost可追踪值班检查单每月扫 administrator 数量应用用户 tags 必须空每个业务 VHost 有且仅有对应 app 账号的 write。guest 若仍存在确认无法从非本机登录。删除 VHost 必须双人先确认删除保护。新同事入职只发自己楼的钥匙不发promo万能账号。把权限表当 Git 文件禁止只在 UI 里点。新人第一周只发只读账号会 declare 之后再开 write避免「先拿万能钥再慢慢收」。三个 VHost 的监控大盘必须带过滤器默认视图不准停在某个开发自己的promo残留上。删除保护要在创建 VHost 的同一变更单里打开事后补开等于没开。口令轮转时先加新用户再切应用配置最后删旧用户避免发布窗口全 403。这些操作写进 runbook比口头「注意安全」有用。跨部门最容易吵的是营销能否只读订单队列做对账。答案是不能直接读生产订单 VHost除非 Shovel 到营销只读副本或导出。只读看起来无害Get 仍会改变队列第 9 章UI 手滑 Purge 更不必说。对账走数仓或 fail 队列导出不走支付队列 Get。把这句话写进安全评审纪要本章才算落地。权限正则建议由架构出初稿、开发确认前缀、测试用拒绝用例锁死、运维负责执行脚本。四步缺一正则就会在某个周五被改成.*「先让过」。每月扫描.*权限命中即工单。guest 用户在实验室可留预发必须删除或确认 loopback。应用配置中心里出现ops_admin口令视为事故。VHost 不是「文件夹」而是独立的权限与存储域经典队列的消息目录按 VHost 分开删楼等于拆盘。所以测试清理不要图省事删 VHost除非那是一次性实验室。预发与生产的 VHost 名单应一致只是用户不同避免「预发在 promo、生产在 order」导致发布当天连错。默认 VHost/只留给 Broker 内部与临时实验业务禁用。迁移期间允许双 VHost 并存用 Shovel 搬历史搬完再关旧权限而不是把两个楼的钥匙都给同一应用。账号生命周期入职开通、转岗改正则、离职删除并踢连接。离职当天close_all_user_connections与删用户同一变更单。外包账号设过期提醒。这些是户口不是可选项。与第 5 章 tags 一起离职用户即使还有 management 标签删用户后 UI 也进不去但别指望标签过期自动失效。把「三栋楼、四类人」画成一页架构图贴 Wiki第 16 章通知中心按图接线。图上必须出现应用无 tag、值班 monitoring、管理员不进应用配置、lab 用户单独一列。缺图则综合实战会重新发明一套账号。连接命名connection_name必须含服务名与实例号list_connections才能踢对进程。没有名字的连接在故障时只能按 IP 猜容器网络下 IP 几乎无意义。第 4 章的 client_properties 在本章变成户口字段不是装饰。4. 项目总结优点与缺点模型优点缺点多 VHost故障与权限爆炸半径小拓扑要声明三遍监控要按 VHost 过滤单 VHost 前缀省事一次 Purge 全局受伤全员 administrator联调快无法审计、无法追责无 tag 应用账号攻击面小调试要另开只读账号优点1隔离可测。2两套闸门分工清楚。3连接能追到人。缺点1正则写错即全站拒或全站开。2权限缓存让测试「改了没生效」。3删 VHost 不可逆。适用场景多事业部共用 Broker。需要最小权限发布列车。事故要追到用户。准备第 16 章把订单与营销拆开演示。不适用十人以下且已有强流程的单一应用可先单 VHost 但仍禁止全员管理员用 VHost 代替集群隔离机房那是第 17 章。注意事项正则顺序 configure/write/read。4.x 可对 VHost 开删除保护。guest 关闭 loopback 等于裸奔。安全管理员口令不准进应用配置中心。跨 VHost 复制消息用 Shovel第 21 章不要给应用双 VHost 写权限图省事。常见踩坑生产营销 Purge 清到订单队列。根因共用 VHost 管理员标签。正则写反应用能删不能读。根因三参数顺序。改权限不重连测试以为没生效于是改成.*。根因缓存 用放开权限当排障。思考题若订单与营销必须「看见同一条支付成功」又不想共享 VHost有哪些复制手段与权限代价topic permission 能否单独禁止*.error之外的发布而普通 write 仍允许该交换机附录 C第 10 章思考题参考答案题 1Ack work 之后 Confirm wait 失败。生产顺序应改为先对 wait 档 Confirm 成功再 Ack work。若已错误 Ack用 outbox/本地表记「待入 wait」扫表补发消费者对 orderId 幂等。禁止靠「再 Nack 一次」——消息已经不在 work。题 2清掉 headers 再发。x-death被抹掉后次数归零三次上限失效形成无限退避或永不到 fail。规范禁止剥离 x-death应用若要自管次数应另写不可变 header如x-retry且只增不删。延伸阅读与资源SQLAlchemy 2.0从入门到进阶的实战之旅Dify 从入门到进阶LLM 应用平台实战修炼Java 工程师进阶从 JVM 生产排障到OpenJDK原理NumPy 从入门到生产落地全链路实战指南科学计算/向量化Redis 8 实战精讲从 CRUD 到源码构建高可用缓存系统Redis 实战修炼与原理进阶Python 3实战精进从脚本到高并发订单引擎python入门Rquests从菜鸟脚本到企业级SDK的网络实战圣经Milvus向量数据库实战修炼从 0 到 1精通向量检索与生产落地MongoDB 实战进阶与内核修炼后端工程师的 AI 转型第一课Ollama 与私有化大模型实战10倍开发者的 Dify 魔法书从零构建全栈 AI 应用后端工程师转型AI第一课-Ollama 与私有化大模型实战大型语言模型(LLM) vLLM 高性能推理落地实战Agent开发之LlamaIndex 实战修炼与源码进阶大语言模型Transformers 实战修炼与源码剖析