Nacos 3.x：控制台分家之后，鉴权到底要不要补

3.x 之前流传最广的那份「打开鉴权」升级清单，前提已经变了：3.x 的鉴权默认就是开的。而更值得说的事情发生在另一处：一批 ADMIN API 的鉴权作用域配错了，从 3.0.0 一直带到 3.2.3。

先把版本现状对齐，再说哪些配置真的要动手。

版本现状（截至 2026 年 9 月）

按 GitHub 上的发布记录：

• 3.0.0 GA：2025-04-27；此后 3.0.1 / 3.0.2 / 3.0.3、3.1.0 / 3.1.1 / 3.1.2、3.2.0 / 3.2.1 / 3.2.2 / 3.2.3。
• 最新常规发布版：3.2.4（2026-08-27）。3.3.0 目前只到 RC（2026-09-21），还没 GA。
• 2.5.4 也在 2026-08-27 发布——同一天。

后面这条要记住：2.x 这条线仍在收维护更新。 所以停在 2.x 目前不是被迫的，而是一个可以选择的状态。下面那条漏洞的存在，恰好让「再等等」变成一个需要重新算的选择。

控制台分家具体改了什么

官方文档的说明是：从 Nacos 3.0 版本开始支持把控制台独立部署，理由是「进一步拆分高风险请求和高资源消耗的请求，从而提高安全性和稳定性」。

这个理由我认同。控制台是低频、面向人的流量，服务端是高频、面向 SDK 的流量；以前两者同进程时，一个页面级的大查询能拖累注册心跳。分开之后可以按不同资源画像分别扩缩，控制台还能只在办公网可达。

运维上的实际差异，比「多起一个进程」多一些：

# 服务端
sh bin/startup.sh -m standalone -d server
# 控制台：把同一个发行包拷到另一台机器，
# 并把服务端的 ip:port 写进控制台自己的 conf/cluster.conf
sh bin/startup.sh -d console

配置	作用
nacos.console.port	控制台端口，默认 8080
nacos.console.contextPath	控制台的路径前缀
nacos.console.remote.server.context-path	控制台访问服务端时用的上下文路径

一个容易忽略的硬性条件：控制台进程要求 JDK 17+。 服务端可以跑在更低版本上，控制台不行——这种不对称通常是升级当天才发现的。

鉴权：默认值确实变了，别照抄旧清单

Nacos 3.0 的发布说明里有一条「Enabled nacos console authentication」，权限校验文档写的是「从 Nacos 3.0 起，控制台访问默认开启鉴权」。现在的默认值是：

配置	3.x 默认
nacos.core.auth.enabled	true
nacos.core.auth.admin.enabled	true
nacos.core.auth.console.enabled	true
nacos.core.auth.system.type	nacos

也就是说，「忘记打开鉴权」这个经典事故前提，在 3.x 上已经不明显成立了（除非显式关掉，文档也明确不建议这么做）。

但默认开了不等于配好了。以下几项默认是空的，空值会让服务起不来或者控制台连不上服务端：

一、nacos.core.auth.plugin.nacos.token.secret.key。 默认空。要填Base64 字符串，且解码后的原始密钥长度不少于 32 字符。实操上 openssl rand -base64 48 出一个就行。

这里要纠正一个流传很广的说法：过去广为流传的「Nacos 自带一个众所周知的默认密钥」，在 3.2 的官方文档里对应默认值写的是空。所以现在的检查点不再是「有没有改掉默认密钥」，而是「有没有真的填上、填的够不够长度」。但另一条仍然成立且更实用：这个值不能出现在任何公开示例里——它一旦被抄进过教程，就有了被伪造 token 的可能。

二、nacos.core.auth.server.identity.key / identity.value。 默认空，而集群节点之间以及控制台到服务端的调用都需要它。三台节点上这一对值必须逐字符一致，否则控制台会连不上服务端。

补充一条能省很多时间的机制：3.x 启动脚本在这些关键项没配时会交互式提示输入。这带来一个新的运维陷阱——手工在终端里启动成功的部署，不代表 systemd 或者容器里能起来，非交互环境下没人回答那个提示。这条一定要在无 TTY 的环境里单独验一次。

三、管理员口令不再内置。 从 2.4.0 起 Nacos 就没有内置默认管理员密码，首次启动要通过 POST /v3/auth/user/admin 这个一次性初始化接口设置。所以口令的来源必须是部署流程，不是某个人的浏览器——手工做那一次的结果是：没人记得密码是怎么来的，而且换实例就得重来。

真正该关注的那件事：3.0.0–3.2.3 的 ADMIN API 鉴权作用域

这是我认为 2026 年 Nacos 这边最该被写的一件事。

阿里云 MSE 官方安全公告（2026-08-31 更新）的表述是：Nacos 社区公开披露了 3.X 版本部分 API 鉴权范围设置错误的漏洞，并于 3.2.4 版本完成修复；在默认情况下应当鉴权的部分 ADMIN API 未鉴权。

可核对的要点：

• 受影响版本：3.0.0 ～ 3.2.3；触发条件里包含 nacos.core.auth.enabled 未设置为 true。
• 修复版本：3.2.4（2026-08-27）。
• 机制上，社区分析指向 user / role 相关 API 缺少 ADMIN_API 作用域标记——也就是认证过了，但授权边界没判，于是可以自建管理员。这类「作用域错配」比「没鉴权」隐蔽得多，因为你的鉴权开关确实是开着的。
• 标识方面要说准确：流传的编号 QVD-2026-59388 是 QVD 编号，不是 CVE，也不是 GHSA。我核过 alibaba/nacos 的已发布 GHSA 列表是空的，OSV 里也没有 nacos 条目。所以目前没有 CVE 编号，引用时不要写成 CVE。

顺带记一笔，避免混淆：CVE-2025-53506 是 Apache Tomcat Coyote 的 DoS，只是在 Nacos 2.5.1 / 3.0.1 的 issue 里被作为传递依赖提出来，不是 Nacos 自身的漏洞。这类「扫出来的 CVE 其实属于依赖」的情况，占了中间件安全单里相当一部分。

3.2.4 除了这条修复，还一并加固了几处：JRaft gRPC 的服务端身份认证（带滚动升级强制）、Admin/HTTP/gRPC/Prometheus 多条路径的鉴权元数据解析、用户名枚举、禁用不安全的 MySQL JDBC 连接选项、以及 MCP 导入白名单。这一串的组合很清楚：它是一次安全集中修订，不是一个普通的 bugfix 版本。 所以我的结论是：3.0.0 到 3.2.3 之间的部署应当直接排到 3.2.4，理由不是「版本新」，而是这一版的改动全落在暴露面上。

升 3.x 会撞上的配置改名

这几条不在安全公告里，但会让升级当场失败：

变化	说明
server.port → nacos.server.main.port	老 key 不再生效，端口会回到默认
server.servlet.contextPath → nacos.server.contextPath	同上，改完访问路径才一致
public 命名空间的 id："" → public	3.2.x 起变了；配置里按空串找 public 的脚本会拿不到
PostgreSQL 场景 3.2.2 起启动校验 tenant_id NOT NULL	存量脏数据会让服务启动失败，不是运行报错

第三条要特别当回事：命名空间 id 是配置的坐标的一部分。存量数据里如果是空串，升级后同一份配置就落在另一个命名空间里，表现是「配置莫名其妙丢了」——而这比报错难查得多。升之前在测试库上把 config_info 的 tenant_id 分布看一遍。

还有一处容易被当成好消息的默认行为要提醒：如果启用了 OIDC 而 authorization-endpoint 留空，非管理员的授权默认是放行的。「接了单点登录」和「做了授权」是两件事，这一条把两者的差距暴露得很直白。

顺手说清 AI Registry 是什么

Nacos 3.x 的另一条主线是把 AI 资源纳入注册体系：3.0.0 提供 MCP 管理，3.1.x 加深 A2A / AgentCard 与代理端点批量注册，3.2.0 补齐 Prompt Registry 与 Skill Registry。官方落地页现在列的是五类资源：Skill、MCP、Agent、Prompt、AgentSpec，并说明「内置于 Nacos 3.2，无需额外部署」。

成熟度该怎么描述：官方既没有把它标成 GA，也没有放进「实验性功能」目录（那个目录里只有分布式锁和 K8s 生态），同时 3.2.4 的说明里提到「默认关闭部分已废弃的 v3 AI API」并留了兼容开关。所以严谨的说法是：它已经是 3.2 的标准组成部分，但 v3 早期那批 AI API 正在被逐步关掉。 要接的话按新 API 接，别复用旧 v3 接口的样例代码。

上线前检查清单

项	怎么验	通过标准
版本	看服务端 /v3 接口返回	3.0.0–3.2.3 一律排到 3.2.4
鉴权真的生效	匿名调一个 ADMIN API	403，而不是数据
token 密钥	检查长度与来源	非空、Base64、解码后 ≥32 字符、不出现在任何教程里
集群互信	三台节点配置逐台 diff	identity.key/value 完全一致
无 TTY 启动	用 systemd 或容器启一次	不卡在交互式提示上
管理员初始化	重启一个实例后再登录	仍能登录
命名空间 id	查 config_info.tenant_id 分布	无空串残留
控制台暴露面	分别从业务网段与公网探 8080	两者都探不到

第三行和第一行是这次真正新增的项。第二行的验证方式值得强调：不要靠读配置文件判断鉴权是否生效，要发一次真实的匿名请求——环境变量、启动参数、cluster.conf 都能覆盖文件里的值。而第一行是因为 3.x 之后，「配置都对但版本在 3.2.3」这一种状态是看得见却最容易漏的：所有检查项都能通过，漏洞依然在。