Topic 权限如何设计？
简化版
Topic 权限应按生产、消费、管理三类动作和环境、租户、消费组分别授权，默认拒绝、最小权限，使用服务身份与短期凭证。不能只控制 Topic 读写，还要限制建删 Topic、改保留/分区、重置位点和重放等高风险管理操作。
详细版
每个工作负载使用独立 service account，生产者只写指定 Topic，消费者只读指定 Topic 且只能管理自己的 group；平台管理员与业务运维职责分离。通配符限制范围，测试和生产使用独立命名空间与凭证，敏感 Topic 再叠加网络隔离和字段加密。
权限变更走审批、到期和审计，密钥由 secret manager 轮换；紧急权限自动失效。持续监控拒绝、异常读取、批量导出、位点重置和 ACL 变更，并定期根据实际使用回收闲置权限。
完整版教学
一、先建立资源与动作模型
资源不只有 Topic，还包括 consumer group、集群、事务 ID、Schema 和管理 API。动作至少分 produce、consume、describe、create、alter、delete 与 offset reset。只做“读/写”两级角色会把危险管理能力混入日常账号。
心法：能读消息、能推进位点、能改 Topic 是三种不同权力。
二、典型权限矩阵
| 身份 | Topic | Group | 管理权限 |
|---|---|---|---|
| 订单生产者 | orders:write | 无 | 无 |
| 积分消费者 | orders:read | points-group | 仅本组提交 |
| 运维只读 | metadata | 无 | describe |
| 平台管理员 | 按审批 | 按审批 | alter/create |
消费者若能操作其他组的 offset，可能让对方重复或漏消费。
三、身份和凭证
使用 mTLS、SASL/OAuth 等服务身份，不共享团队账号。凭证存 Secret Manager，短期签发并自动轮换；应用日志不得打印 token。实例身份应与部署环境绑定，拷贝配置文件不能直接获得生产权限。
workload identity -> short-lived credential -> broker ACL人员临时排障走单独身份、工单和到期授权。
四、通配符与环境隔离
prod-* 写权限可能覆盖未来新增的敏感 Topic，通配符要限定业务命名空间和动作。开发、测试、生产最好使用独立集群或强命名空间，禁止测试消费者误订阅生产。
多租户还要在 Topic、group、配额和加密密钥上隔离，不能只依赖名称约定。
授权与配额是两层控制：ACL 决定能否访问，配额限制访问速率；合法但失控的生产者仍可能占满 Broker，因此两者不能互相替代。
五、高风险操作
建删 Topic、缩短保留、增加分区、重置位点、批量重放和修改 ACL 都可能造成不可逆影响，应使用控制面角色和双人审批。应用运行身份不需要这些能力。
例如消费服务只需提交自己的位点，不应拥有把 group 跳到 latest 的权限；重置通过审计工具执行并保存前后值。
Schema Registry、密钥管理和归档存储应使用与 Topic 一致的主体边界，否则用户可能绕过 Broker ACL 从旁路读取内容或发布不兼容 Schema。
六、审计、检测与回收
记录主体、来源、资源、动作、结果和 requestId；对 ACL 变更、跨租户读取、大量下载和连续拒绝告警。权限盘点对比近 90 天实际使用，回收离职、下线服务和未使用通配权限。
Break-glass 权限应自动在 1 小时等短窗口过期，事后复盘实际访问。Broker 授权之外还需网络策略与消息字段最小化。
七、常见误区与追问
- 误区：内网 MQ 不需要鉴权。 内网凭证泄露和横向移动同样存在。
- 误区：消费者有 Topic 读权即可。 还要约束可操作的 group。
- 误区：通配符方便且风险不大。 新 Topic 会自动继承超出预期的权限。
- 误区：管理员账号可给应用使用。 应用无需建删和改配置能力。
- 追问：如何做紧急排障？ 临时身份、审批、短期到期和全量审计。
- 追问：ACL 足够保护敏感数据吗？ 还需网络隔离、加密、脱敏和最小字段。
- 追问：如何发现过度授权？ 对比权限与实际访问，并周期回收闲置能力。
八、加强记忆
Topic 权限按“主体—资源—动作—环境—期限”设计：服务身份独立，生产/消费/group/管理拆权，默认拒绝并限制通配符。高风险操作走审计控制面，短期凭证和定期回收降低长期暴露，再用网络与数据层防护形成纵深安全。