Apache Pulsar 版本支持与安全管理实操指南：漏洞上报、支持窗口与跨版本升级顺序

【免费下载链接】pulsarApache Pulsar - distributed pub-sub messaging system项目地址: https://gitcode.com/gh_mirrors/pulsar28/pulsar

Apache Pulsar 的安全策略和版本支持规则，入口是仓库根目录的 SECURITY.md，正文则放在 docs 目录的安全策略页面里。这篇文章不按条款逐条念政策，而是直接回答四个运维问题：漏洞公告来了先查什么、手里的版本还能不能用、跨版本升级的正确顺序、自己发现漏洞要走哪几个地址。内容基于本仓库 2.10.x 代码库（版本号定义见 pom.xml，当前为 2.10.6-SNAPSHOT），快照型信息一律标注出处时效。

漏洞公告来了，先查哪三件事

收到users@pulsar.apache.org列表上的安全通知时，别急着升级，先完成三项核对。

社区在漏洞确认并修复后，会在这个邮件列表发布公告细节与缓解建议。运维侧的标准动作是订阅该列表，它有三个用途：第一时间知道已发布版本出了什么问题；拿到官方推荐的升级目标和临时规避手段；对"哪些版本还受支持"拿不准时，也可以直接在这个列表里问社区求证。

公告到手后按这个顺序处理：

1. 对照自己的版本台账：每个环境（测试/预发/生产）当前跑的是哪个版本、Initial Release 是哪个月；
2. 判断是否还在支持窗口内——12 个月的维护承诺是关键判断线，已超窗的分支连安全补丁都不会再出，只能排升级；
3. 先落公告里的临时缓解（关特性、收紧防火墙规则），再评估升级窗口，两条线并行。

📮 自己发现漏洞：两个地址走通上报路径

主渠道是 Apache 软件基金会的统一安全地址，同时抄送 Pulsar 私有列表。

• 主收件地址：security@apache.org，覆盖整个 Apache 生态的漏洞接收；
• 抄送地址：private@pulsar.apache.org，这是一个私有邮件列表，内容不对外公开，作用是在修复完成前限制传播范围，同时让 Pulsar 的 PMC 更快介入。

报告正文建议给全四样东西，能显著加快复现与定级：受影响的版本（如 2.8.x、2.9.x）；漏洞类型与可复现步骤，有 PoC 更好；受影响组件（broker、bookie、proxy、client 还是函数运行时）；实际影响评估（未授权访问、数据泄露、拒绝服务等）。

修复并公告之前，不要在 GitHub Issue 或公开邮件列表里贴细节，避免 0-day 提前暴露。

🔐 你的集群是否处于"默认全开放"状态

开箱即用的 Pulsar 不配置任何加密、认证与授权：任何客户端都能用明文 Service URL 跟集群通信。生产环境必须用网络安全隔离或授权 ACL 把访问限制在可信客户端内，否则等于裸奔。

对照安全总览文档 site2/docs/security-overview.md 逐项核对四项：

• TLS 传输加密（含双向认证与 KeyStore 方式）；
• 认证：Pulsar 是可插拔设计，支持 TLS 认证、Athenz、Kerberos、JWT、OAuth2 等 Provider；
• 授权 ACL：认证通过后，broker 以 principal 作为后续授权依据；
• 端到端加密（含 Bouncy Castle 集成）。

连接建立时 broker 会校验认证凭据，通过后连接不会反复重认证。真正负责凭据续命的是周期性检查：authenticationRefreshCheckSeconds参数默认 60 秒，可在 conf/broker.conf 中调整，broker 按该周期检查每个连接——凭据过期就强制重新认证，支持refreshAuthentication的客户端会刷新凭据，不支持且过期的连接会被直接断开。配置这套机制时，60 秒这个默认值要和你签发 token 的有效期对齐。

⏱️ 这个版本还能用吗：12 个月窗口的算法

一个功能发布分支（某个次版本系列，如 2.5.x）在首次发布后至少维护 12 个月，超期后不再有任何发布——包括安全漏洞修复。

算一笔账就明白了：2.5.0 于 2020 年 1 月发布，那么 2021 年 1 月起，2.5.x 就不再被视为受维护版本。12 个月是下限不是上限：部分次版本在窗口过后仍会被继续维护，比如 2.7 在文档编写时还处在活跃维护状态。窗口期内，安全修复回溯到旧版本的优先级最高；但要清楚，最新版本永远拥有最多的 bug 修复，停在旧版本等于主动放弃一部分修复。

上表是官方文档编写时刻的快照，社区会随每个新版本发布刷新这张表，判定前请以官方最新版安全策略页面为准；拿不准的，直接在users@pulsar.apache.org列表问。

还有一个未定项：3.0.0 发布后 2.x 怎么支持尚未定论，一种讨论中的方案是把 2.x 的最后一个次版本作为 LTS 延长维护，但没有官方决定之前，不要假设任何版本的 LTS 身份。

⬆️ 跨版本升级顺序：书里怎么排就别跳着走

升级已有集群必须线性地穿过每个次版本：从 2.8.x 到 2.10.x，必须先到 2.9.x，再进 2.10.x，跨次版本跳跃会踩兼容性边界——Pulsar 的元数据格式、存储协议和 broker 间通信协议都在次版本间演进。

集群由 ZooKeeper（配置存储）、bookies（有状态存储节点）、broker 与 proxy（无状态服务）组成，官方升级手册在 site2/docs/administration-upgrade.md，推荐的执行顺序：

1. 先升级 bookies；
2. 再升级 brokers、proxies；
3. 最后升级客户端；
4. ZooKeeper 一般可以保持不动。

每个组件都先做小范围 canary test，观察无异常后再全量滚动。两个容易漏掉的细节：启用了autorecovery时，bookie 升级前执行bin/bookkeeper shell autorecovery -disable，升级完成后执行bin/bookkeeper shell autorecovery -enable恢复；bookie 建议先以只读模式跑新版本验证，bin/pulsar bookie --readOnly确认正常后，再用bin/pulsar bookie切回读写。

📅 按发布节奏规划升级窗口

社区通过了 PIP-47（Time Based Release Plan），发布节奏因此可预期：每年 4 个次版本，大约每季度一个，新功能按季度稳定交付；补丁版本按需发布，安全修复出现时会紧急出 patch，不用等季度窗口。

落到排期上就是两句话：功能演进和升级窗口按季度规划；给安全补丁单独留一条应急通道，别让它挤占或拖累季度升级计划。

收尾：三步落地

1. 建台账：记录各环境版本与首次发布日期，设 12 个月窗口倒计时提醒；
2. 通渠道：订阅users@pulsar.apache.org，把security@apache.org（抄送private@pulsar.apache.org）的上报路径写进应急预案；
3. 按序升：逐次版本线性升级，bookie 优先、canary 先行、autorecovery 正确启停，不跳版本。

【免费下载链接】pulsarApache Pulsar - distributed pub-sub messaging system项目地址: https://gitcode.com/gh_mirrors/pulsar28/pulsar