6.2 认证授权与多租户治理
6.2 认证授权与多租户治理
本节摘要：共享集群的三道治理闸门：认证回答"你是谁"，授权回答"你能碰什么"，配额回答"你最多用多少"。本节把 TLS 与令牌认证、基于角色的授权、发布消费限速与存储配额一次配齐，并给出从建租户到上线的完整治理演练。
安全不是一道锁，是一串闸门
把安全当一道锁的团队，通常在生产事故后才学会分闸。Pulsar 的治理模型天然分闸，因为它要回答的是三个不同的组织问题。认证（authentication）：连接者是谁——这是身份问题。授权（authorization）：这个身份能对哪些资源做什么——这是权限问题。配额（quota）：即便权限齐全，你最多能用掉多少——这是容量契约。三闸独立配置、层层递进：过了认证没授权，碰不了资源；过了授权超配额，会被限流。
一、认证：给每个连接发身份证
生产环境最常用的两件套是 TLS 与令牌认证。TLS 解决传输加密与双向身份：客户端验证 Broker 证书防冒充，Broker 也可要求客户端证书。令牌认证则用签名的短凭证标识身份：运维用私钥签发带角色声明的令牌，客户端持令牌连接，Broker 用公钥验签——密钥只在签发方手里，吊销与轮换都可控。
# 生成签名密钥对（管理机操作，私钥妥善保管） $ pulsar tokens create-key-pair --output-private-key jwt-private.pem \ --output-public-key jwt-public.pem # 为风控服务的角色签发令牌 $ pulsar tokens create --private-key jwt-private.pem \ --subject risk-service --expiry-time 30d # 输出一串令牌字符串，交付给风控服务作为连接凭证 # Broker 侧开启令牌认证与 TLS 传输（配置要点摘录，供核对方向） # authenticationEnabled=true，认证提供方设为令牌校验， # publicAddress 与监听端口按证书域名规划
配置核对比配置本身更值得强调：认证开启后，所有旧的无凭证连接会被拒绝——先给存量服务签完令牌，再开认证开关，切换顺序错了就是全局断连事故。
二、授权：角色对资源的动作表
授权的单位是"角色对资源的动作"。第 1 章的三级户籍在这里显出第二重价值：权限可以按租户、命名空间、主题三个粒度授予，粒度越细越贴合最小权限原则。给风控服务做一次完整授权：
# 给 risk-service 角色授予订单命名空间的消费与生产权限 $ pulsar-admin namespaces grant-permission trade-order/transaction \ --role risk-service --actions produce,consume # 更细的场景：只允许它消费死信主题（检查员角色） $ pulsar-admin topics grant-permission \ persistent://trade-order/transaction/order-events-RISK-DLQ \ --role risk-inspector --actions consume,functions # 审计：查某命名空间当前的授权表 $ pulsar-admin namespaces permissions trade-order/transaction # 输出：risk-service -> [produce, consume] 等条目
权限治理的实战经验只有一条值得反复强调：角色跟着服务走，不跟着人走。每个服务一个角色一副令牌，人员变动不影响授权表；出问题时按角色定位服务，审计链路清晰。把角色按人配的团队，通常半年后就分不清哪个权限是给谁的。
三、配额与限流：容量契约的落地
权限管"能不能"，配额管"多少算过分"。Pulsar 的配额体系覆盖三面：发布限速防止单个命名空间的写入洪峰挤占共享集群；消费限速控制单个订阅的拉取节奏；存储配额限制命名空间占据的账本容量，超限后的策略（拒写、卸载、告警）可配。订单域做一次容量契约：
# 发布限速：交易域每秒至多五万条进入 $ pulsar-admin namespaces set-publish-rate trade-order/transaction \ --publish-rate 50000 # 分发限速：卡住出水口，该域每秒至多分发八万条 $ pulsar-admin namespaces set-dispatch-rate trade-order/transaction \ --dispatch-rate 80000 # publish-rate 卡进水口，dispatch-rate 卡出水口；存储容量另有配额项可按需叠加 # 观察限流是否生效：被限流的生产端会出现限流错误回调，监控面错误率抬升
配额的哲学要与 6.1 的监控连起来读：配额是"事前合同"，监控是"事中发现"，告警是"事后追责"。三者共用同一套指标，只是介入时机不同。容量契约谈好后写进团队文档，配额调整走变更流程——它本质上是 SLO 的一部分。
图 6-2 三级租户与三闸治理的对应关系
接入流程演练：一个新服务从申请到上线
治理配置散落在三闸里，串成流程才好执行。以库存服务申请接入订单主题为例走一遍全流程：业务方提交接入单（声明消费模式、预期吞吐、保留需求）；平台侧三步操作——为服务建角色并签发令牌、按最小权限授予目标主题的对应动作、按申报吞吐设置或核对所在命名空间的配额；交付三样东西——令牌、服务地址、订阅名命名（按规范）。上线后一周内，平台侧回看该订阅的积压与限流触发记录，确认申报吞吐与真实流量匹配，超出或严重闲置都回头调配额。这套流程看着繁琐，实则把"谁在用、用多少、凭什么"三个审计问题一次性钉死，事故追溯时按角色与订阅名一查即达。
流程里最容易省掉又最不该省的一步是配额核对。新服务上线初期流量往往与申报值相去甚远，配额定太高起不到护栏作用，定太低则上线即限流、业务侧第一印象就坏。回看机制让配额变成"先估、后校、再定"的动态契约，共享集群的公平性靠这类小事积出来。
本节要点回顾
- 治理三闸各答一问：认证定身份、授权定权限、配额定容量；
- 令牌认证加 TLS 是生产标配，先签凭证后开开关，顺序不可颠倒；
- 授权三粒度随取随用，角色跟着服务走是审计清晰的前提；
- 发布限速、分发限速、存储配额分别卡住水道的进水口、出水口与库容；
- 配额是容量契约的一部分，与监控告警共用指标、分时机介入。
下一站驶向远洋：Functions 让水道自己干活，事务护住原子性，云原生指引下一程。