Nacos 2.x 安全升级实战：彻底修复CVE-2021-29441漏洞的配置指南-育师

1. 项目概述：一次看似成功实则“埋雷”的Nacos升级

最近在帮一个项目做中间件升级，核心任务是把Nacos从1.2.1版本升级到2.0.3。表面上看，升级过程挺顺利，服务注册发现、配置管理功能都正常。但当我用安全扫描工具例行检查时，警报响了——那个在Nacos 1.x时代臭名昭著的CVE-2021-29441未授权访问漏洞，扫描报告竟然显示“仍然存在”。这可就奇怪了，官方在2.x版本中已经修复了这个漏洞，为什么还会被扫出来？问题大概率出在升级后的配置上，尤其是那个关键的auth参数。很多团队升级时，只是简单替换了JAR包或者Docker镜像，却忽略了配置文件的适配，导致新版本的安全机制没有完全生效，相当于给系统留了一个“后门”。这篇文章，我就结合这次踩坑和修复的经历，手把手带你搞清楚Nacos 2.x的安全机制变化，并给出确保漏洞被彻底修复的正确配置姿势。

2. 漏洞原理与升级陷阱深度解析

2.1 CVE-2021-29441漏洞的本质

CVE-2021-29441是一个Nacos在1.x版本中存在的高危未授权访问漏洞。它的核心问题在于Nacos的控制台（console）和API接口在默认配置下，缺乏有效的身份认证（Authentication）和授权（Authorization）校验。攻击者无需任何用户名密码，就可以直接访问Nacos的管理界面，进行诸如查看、修改、删除所有配置信息，甚至操作服务实例等危险操作。在微服务架构中，配置中心存储着数据库连接串、第三方服务密钥、业务开关等核心敏感信息，一旦泄露或被篡改，后果不堪设想。这个漏洞之所以影响广泛，是因为早期很多开发者为了图省事，直接在测试甚至生产环境以默认配置（即未开启鉴权）运行Nacos，埋下了巨大的安全隐患。

2.2 从1.x到2.x：安全架构的演进与认知误区

Nacos 2.0版本在架构和安全上是一次重大升级。针对鉴权，2.x版本引入了更完善、插件化的安全模块。在1.x版本中，鉴权功能相对薄弱且配置分散；而在2.x中，鉴权成为一个核心且必须显式配置的功能。官方修复CVE-2021-29441的方式，并不是简单地在代码里加个“补丁”，而是重构了安全体系，强制要求用户通过配置来明确开启并正确使用鉴权。

这里就产生了第一个认知误区：“升级版本号就等于修复了漏洞”。很多运维同学认为，只要把nacos-server的版本从1.2.1换成2.0.3，漏洞自然就没了。实际上，如果沿用旧的、未开启鉴权的配置文件（如application.properties）启动2.0.3的服务，Nacos仍然会以“兼容模式”或“未开启鉴权”的状态运行。安全扫描工具通过探测特定的API路径（如/nacos/v1/auth/users?pageNo=1&pageSize=9）是否能够未授权访问，来判断漏洞是否存在。在这种情况下，扫描结果依然是阳性，漏洞“看似”还在。

第二个误区是：“开启了鉴权就万事大吉”。Nacos 2.x的鉴权配置比1.x要复杂一些，涉及多个参数的联动。仅仅在配置文件中将nacos.core.auth.enabled设为true，只是打开了鉴权系统的总开关。如果像nacos.core.auth.server.identity.key和nacos.core.auth.server.identity.value这类用于服务端自身认证的关键参数配置不当或过于简单，同样可能被绕过或破解，导致鉴权形同虚设。

3. 核心配置参数详解与正确配置指南

要让Nacos 2.0.3的鉴权真正生效、堵住CVE-2021-29441漏洞，必须对以下几个核心参数有透彻的理解并进行正确配置。我们以最常用的application.properties配置方式为例。

3.1 基础鉴权开关与模式选择

首先，必须确保鉴权功能是全局开启的。这是所有安全配置的基石。

# 开启鉴权系统。这个参数必须设置为true，否则所有后续鉴权配置均无效。 nacos.core.auth.enabled=true # 鉴权系统类型。默认为`nacos`，即使用Nacos内置的用户体系。 # 如果企业有统一的LDAP或OAUTH2服务，可以扩展为对应的插件，但本文聚焦于内置系统。 nacos.core.auth.system.type=nacos

注意：在从1.x升级时，请务必检查旧的配置文件中是否存在nacos.core.auth.enabled=false或根本没有这一行。如果是，必须显式修改为true。很多升级后漏洞仍在的情况，根源就在这里。

3.2 身份标识（Identity）配置：防止服务端伪装攻击

这是2.x版本新增的、非常重要但常被忽略的安全增强配置。它的作用是给Nacos服务端自身一个“身份证”，在一些敏感操作（如用户管理）时，客户端（包括控制台）需要出示这个“身份证”来证明自己是受信任的，而不是一个恶意仿冒的请求。

# 服务端身份标识的键（Key）。可以理解为一个令牌的名称。 nacos.core.auth.server.identity.key=example-identity-key # 服务端身份标识的值（Value）。这是实际的令牌内容，必须是一个足够复杂、难以猜测的字符串。 nacos.core.auth.server.identity.value=YourSuperSecretIdentityValueHere@2023

配置要点与避坑指南：

严禁使用默认值：早期一些教程或默认配置示例中，可能会使用serverIdentity作为key，security作为value。绝对不要在生产环境使用这些公开的默认值！攻击者会首先尝试这些常见值进行绕过。
Value值必须强密码化：identity.value应当像数据库密码一样被对待。建议使用密码生成器生成一个包含大小写字母、数字和特殊字符的、长度超过16位的随机字符串。
保密管理：这个值只需要在Nacos服务端的配置文件中设置。它不应该出现在客户端（如Spring Boot应用的bootstrap.yml）的配置里。客户端是通过用户名/密码登录后获取访问令牌（Token）来通信的，而不是这个服务端身份标识。

3.3 用户密码加密与持久化

Nacos默认将用户信息（用户名、密码）持久化到内嵌数据库（Derby）或外置MySQL中。存储明文密码是极不安全的，因此必须启用密码加密。

# 开启密码加密功能。强烈建议开启。 nacos.core.auth.enable.userAgentAuthEncrypt=true # 设置密码加密的密钥（Cipher Key）。用于AES加密算法。 # 同样，必须将其修改为一个自定义的、复杂的字符串，切勿使用 `nacos` 这个默认值。 nacos.core.auth.encrypt.secret.key=YourCustomSecretKeyForEncryption123!

实操心得：在初始化或升级后第一次启动Nacos前，就设置好secret.key。如果启动后已有用户数据，再修改此密钥，会导致之前存储的加密密码无法解密，现有用户将无法登录。如果遇到这种情况，需要清空用户表（如users表），或者使用新的密钥重新初始化。

3.4 客户端访问配置（非漏洞修复必需，但关乎正常使用）

开启服务端鉴权后，所有访问Nacos的客户端（包括其他微服务、运维人员通过控制台）都必须提供身份凭证。

对于Spring Boot/Cloud Alibaba客户端，需要在bootstrap.yml或application.yml中配置：

spring: cloud: nacos: discovery: server-addr: localhost:8848 username: nacos # 默认管理员用户名 password: nacos # 默认管理员密码，首次登录后必须修改！ config: server-addr: localhost:8848 username: nacos password: nacos

重要提醒：首次使用默认账号（nacos/nacos）登录控制台后，首要任务就是修改这个超级管理员密码，并创建具有不同权限的、专用于业务服务的低权限账号，替换掉客户端配置中的默认账号。遵循最小权限原则。

4. 完整升级与安全配置实操流程

假设我们从一个未开启鉴权的Nacos 1.2.1环境，升级到一个安全加固的Nacos 2.0.3环境。这里以使用Docker-Compose部署为例，物理机或K8s部署思路类似。

4.1 第一步：备份与准备

备份数据：备份Nacos 1.2.1的数据目录（通常是~/nacos/data或${NACOS_HOME}/data）和配置文件（conf目录）。这是升级的铁律。
准备新版本配置文件：解压或下载Nacos 2.0.3的发布包，将其conf目录复制到你的工作区进行修改。我们重点关注application.properties。
规划密钥：提前准备好两个强密码：
- SERVER_IDENTITY_VALUE：用于nacos.core.auth.server.identity.value。
- ENCRYPT_SECRET_KEY：用于nacos.core.auth.encrypt.secret.key。

4.2 第二步：编写安全的配置文件

创建一个新的application.properties文件，内容如下（关键部分已高亮）：

# 开启鉴权 nacos.core.auth.enabled=true nacos.core.auth.system.type=nacos # 配置强服务端身份标识 nacos.core.auth.server.identity.key=my-server-identity nacos.core.auth.server.identity.value=${SERVER_IDENTITY_VALUE:YourStrongIdentityValue!@#987} # 开启并配置密码加密 nacos.core.auth.enable.userAgentAuthEncrypt=true nacos.core.auth.encrypt.secret.key=${ENCRYPT_SECRET_KEY:YourStrongEncryptKey456$%^} # 其他必要配置（如数据库，如果使用MySQL） spring.datasource.platform=mysql db.num=1 db.url.0=jdbc:mysql://your-mysql:3306/nacos_config?characterEncoding=utf8&connectTimeout=1000&socketTimeout=3000&autoReconnect=true db.user=nacos db.password=your_mysql_password # 建议关闭默认的“公开”命名空间写权限，增强安全 nacos.core.auth.default.namespace.write.enable=false

提示：上面使用了${VAR:default}语法，目的是为了在Docker等环境中通过环境变量传入密钥，避免密码硬编码在配置文件中。这是更安全的做法。

4.3 第三步：使用Docker-Compose部署

编写docker-compose.yml文件：

version: '3.8' services: nacos: image: nacos/nacos-server:v2.0.3 container_name: nacos-server restart: always volumes: - ./data:/home/nacos/data # 挂载数据目录，持久化 - ./logs:/home/nacos/logs # 挂载日志目录 - ./custom-application.properties:/home/nacos/conf/application.properties # 挂载自定义配置 ports: - "8848:8848" - "9848:9848" # Nacos 2.0新增的gRPC端口，必须暴露 - "9849:9849" # 用于节点间RPC通信，集群模式下需要 environment: - MODE=standalone # 单机模式，集群模式请参考官方文档 - NACOS_AUTH_ENABLE=true - NACOS_AUTH_IDENTITY_KEY=my-server-identity - NACOS_AUTH_IDENTITY_VALUE=YourStrongIdentityValue!@#987 # 通过环境变量传入 - NACOS_AUTH_ENCRYPT_SECRET_KEY=YourStrongEncryptKey456$%^ # 通过环境变量传入 - JVM_XMS=512m - JVM_XMX=512m

关键点说明：

9848和9849端口：Nacos 2.x使用gRPC进行客户端-服务器和服务器-服务器通信，性能更高。如果防火墙或安全组未开放这些端口，客户端将无法连接。
环境变量：Nacos Docker镜像支持通过环境变量覆盖application.properties中的配置。我们这里同时使用了挂载配置文件和环境变量两种方式，环境变量优先级更高，更灵活。

4.4 第四步：启动、验证与客户端适配

启动服务：在docker-compose.yml所在目录执行docker-compose up -d。
验证控制台访问：浏览器打开http://your-server-ip:8848/nacos。此时应该跳转到登录页面，而不是直接进入控制台。使用默认账号nacos/nacos登录。
立即修改密码：登录后，进入【权限控制】->【用户管理】，立即修改nacos用户的密码。
创建业务账号：新建一个角色为GLOBAL_READER或GLOBAL_WRITER（根据需求）的用户，例如app-user，用于微服务客户端连接。
更新客户端配置：将所有微服务项目的配置文件中，Nacos的username和password更新为新建的业务账号。如果之前客户端配置里没有这些项，现在必须加上。
重启客户端服务：重启微服务应用，确保它们能使用新的凭证成功连接到Nacos。

5. 漏洞修复验证与常见问题排查

完成上述配置后，如何确认CVE-2021-29441漏洞真的被修复了？

5.1 手动验证方法

未登录访问控制台：打开浏览器无痕窗口，直接访问Nacos控制台地址。应重定向至登录页，无法看到任何数据。
直接调用未授权API：使用curl命令测试。
```
# 测试一个需要鉴权的API，例如查询用户列表 curl -X GET 'http://your-nacos-server:8848/nacos/v1/auth/users?pageNo=1&pageSize=9'
```
预期结果：返回{"code":403,"message":"unknown user!","data":null}或类似的403错误。如果返回200 OK并包含用户列表，则说明鉴权未生效。

5.2 安全扫描工具验证

使用专业的漏洞扫描工具（如AWVS、Nessus，或开源工具如nuclei）对Nacos服务端地址进行扫描。针对CVE-2021-29441的检测插件应该会返回“已修复”或“低风险”状态。请确保扫描器规则库已更新，能识别Nacos 2.x的版本和接口。

5.3 常见问题排查表

问题现象	可能原因	解决方案
升级后，客户端报`403`或`unknown user`错误。	1. 客户端配置未添加`username`/`password`。 2. 使用的账号密码错误或权限不足。 3. 服务端鉴权未正确开启。	1. 检查客户端配置，确保已添加正确的认证信息。 2. 登录控制台确认账号密码及权限。 3. 检查服务端`application.properties`中`nacos.core.auth.enabled`是否为`true`。
控制台可以免密登录，或登录后仍能未授权访问API。	1.`nacos.core.auth.enabled`仍为`false`。 2.`server.identity.key/value`配置为默认值或过于简单，被扫描器规则匹配到。 3. 配置未生效（如挂载路径错误）。	1. 确认配置项已正确设置并重启服务。 2. 将`identity.key`和`value`修改为复杂、唯一的自定义值。 3. 进入容器内部检查`cat /home/nacos/conf/application.properties`确认最终配置。
修改`encrypt.secret.key`后，老用户无法登录。	密钥变更导致存储的加密密码无法解密。	1. 使用新密钥初始化系统（清空用户表，风险大）。 2.推荐：在初次配置时就设定好强密钥，并备份。如果已发生，可通过数据库工具，将`users`表中对应用户的`password`字段更新为新密码（经新密钥加密后的密文），加密逻辑可参考Nacos源码或使用简单程序生成。
客户端连接失败，报连接超时或`grpc`相关错误。	Nacos 2.x的`9848`端口未开放。	检查服务器防火墙、云服务商安全组、Docker端口映射，确保`8848`(HTTP) 和`9848`(gRPC) 端口均已正确开放。
Docker启动失败，日志提示`identity`或`secret.key`相关错误。	环境变量或配置文件中，密钥字符串包含特殊字符（如`$`,`!`,`#`）未正确处理。	在Docker环境变量中，对于包含特殊字符的值，建议使用单引号包裹，或在`docker-compose.yml`中使用`environment`文件`.env`来管理。在`application.properties`中，特殊字符通常不需要转义。

最后一点个人体会：中间件升级，尤其是涉及安全漏洞修复的升级，绝不仅仅是替换二进制文件那么简单。它更像是一次对系统安全配置的重新审视和加固。对于Nacos这类核心基础设施，开启鉴权、使用强密码、按需分配权限、定期更新，这些安全基线必须成为部署规范的一部分。每次升级后，养成用工具扫描和手动验证的习惯，才能真正做到心里有底，把漏洞风险关进笼子里。