Nacos 认证关闭的代价有多大Nacos 从测试环境推到了生产。部署脚本跑得很顺利——解压、改 cluster.conf、startup.sh。8848 端口通了服务注册正常灰度发布正常。20 分钟后在公网扫到了这个 8848 端口拿到了所有命名空间下的所有配置——数据库密码、Redis 密码、消息队列的 AK/SK、第三方支付的密钥。全部明文。一览无余。问题出在哪Nacos 2.x 的认证默认是关闭的。application.properties里一行nacos.core.auth.enabled默认为 false。新部署的 Nacos 控制台直接裸在 8848 端口上任何人都能访问。本文基于 Nacos 2.3.x一步一步把认证锁死——不只是打开开关而是把账号、密钥、权限、namespace 四个层面都封住。⚠️ 本文基于 Nacos 2.3.x2024年12月发布。如果你是 1.x 版本1.4.x 及以下认证机制完全不同——1.x 使用nacos.core.auth.default.token.secret.key作为默认密钥不推荐生产继续使用。⚠️ 如果你正在运行一个认证未开启的 Nacos 实例先改配置立即重启。在此期间在防火墙层临时封掉 8848 和 9848 的入站流量。前置条件项目说明Nacos 版本2.3.x推荐最新稳定版数据库MySQL 5.7 或 8.0cluster 模式必须操作系统Linux本文以 CentOS 7 为例其他 Linux 同理客户端版本nacos-client 2.3.0操作权限Nacos 部署目录的读写权限 MySQL 的 DDL 权限 如果你还没部署 Nacos先看这篇集群部署Nacos 集群部署——3 台机器7 个步骤1 小时上线第一步打开认证开关 替换密钥1.1 修改 application.properties# 文件nacos/conf/application.properties # 认证开关生产环境必须 true nacos.core.auth.enabledtrue nacos.core.auth.system.typenacos # 自定义身份认证密钥 # 必须替换为新的 Base64 编码密钥长度≥32字符 # 生成方式openssl rand -base64 32 # 示例不要直接用这个自己生成 nacos.core.auth.plugin.nacos.token.secret.keyVGhpc0lzTXlDdXN0b21TZWNyZXRLZXlGb3JOYWNvc0F1dGhBbmRTZWN1cml0eQ # 身份认证过期时间秒 nacos.core.auth.plugin.nacos.token.expire.seconds18000 # 服务端默认关闭通过 User-Agent 识别请求来源 nacos.core.auth.enable.userAgentAuthWhitefalse每行参数的作用参数作用不改的后果auth.enabledtrue开启认证不开裸奔token.secret.keyJWT 签名的密钥用默认值所有人都能用默认密钥伪造 Tokentoken.expire.secondsToken 有效期默认18000s5h太长Token泄漏后长期有效太短频繁重新登录userAgentAuthWhitefalse禁止通过 User-Agent 绕过认证设为 true某些 HTTP 客户端可以不走认证1.2 生成自己的密钥# 在 Linux/Mac 上执行openssl rand-base6432# 输出类似VGhpc0lzTXlDdXN0b21TZWNyZXRLZXlGb3JOYWNvc0F1dGhBbmRTZWN1cml0eQ把输出的字符串填到token.secret.key里。每个 Nacos 节点用同一个密钥。密钥不匹配的节点认证全部失败客户端直接无法连接。 Nacos 2.x 使用 JWTJSON Web Token做身份认证和 1.x 的固定 Token 机制不同。用默认密钥等于没认证——原理拆过临时实例走左边持久化走右边——拆开那 3 行 if 里的认证链路1.3 重启并验证cdnacos/binshshutdown.shshstartup.sh-mcluster# cluster 或 standalone# 验证认证是否生效# 访问控制台 → 应强制跳转登录页# 直接 curl API → 应返回 403curl-XPOSThttp://localhost:8848/nacos/v1/cs/configs?dataIdtestgroupDEFAULT_GROUP# 期望输出{timestamp:...,status:403,error:Forbidden,message:unknown user!,path:/nacos/v1/cs/configs}验证清单控制台需要登录才能访问未登录状态下直接调用 API 返回 403默认账号 nacos/nacos 可以登录所有集群节点使用相同的token.secret.key第二步修改默认管理员密码认证打开后第一个要改的就是默认密码。nacos/nacos 是最容易被扫到的凭证。2.1 控制台方式推荐登录 Nacos 控制台 → 权限控制 → 用户列表 → 找到 nacos 用户 → 修改密码。2.2 SQL 方式集群模式-- 连接到 Nacos 使用的 MySQL 数据库USEnacos_config;-- 直接修改 users 表-- BCryptPasswordEncoder 加密新密码-- 以下示例密码为 Nacos2024Prod用自己的替换UPDATEusersSETpassword$2a$10$EuWPZUmCZ4G3GkIuLIL7COoNJ3kZ5HmQU7qO3P/hVSqFE2wAMNdReWHEREusernamenacos;新密码建议至少 12 位包含大写、小写、数字、特殊字符不包含 nacos、admin、root 等常见词使用了 BCrypt 加密后存储什么时候用 SQL 方式批量初始化或自动化部署脚本场景下。日常管理用控制台即可。第三步按 Namespace 隔离权限认证开完后所有人的权限是一样的——都能看所有 namespace、所有配置。生产环境需要按环境、按团队做隔离。3.1 创建 Namespace 专属角色Nacos 2.x 的角色体系是角色 → 权限 → 资源。用户 张三prod 运维角色ROLE_PROD_ADMIN用户 李四dev 开发角色ROLE_DEV_USER权限对 prod namespace所有配置的读写权限对 dev namespace配置的只读控制台操作路径权限控制 → 角色管理 → 新建角色 角色名: ROLE_PROD_CONFIG_ADMIN 用户名: 不填后续绑定用户 权限: resource: prod/*/* action: rw字段含义resource资源路径格式namespace/group/dataId*代表通配actionr只读w只写rw读写3.2 常用权限配置模板角色resourceaction适用场景生产配置管理员prod/*/*rw可以修改生产所有配置生产配置只读prod/*/*r只能看生产配置不能改开发环境全权dev/*/*rw开发环境随便改灰度发布专用gray/DEFAULT_GROUP/*rw只能操作灰度环境的配置注册中心管理prod/*/nacos*rw只能管理注册中心相关配置3.3 新建用户并绑定角色-- 自动化场景下用 SQL 批量创建用户INSERTINTOusers(username,password,enabled)VALUES(zhangsan_prod,$2a$10$...,1);INSERTINTOroles(username,role)VALUES(zhangsan_prod,ROLE_PROD_CONFIG_ADMIN);⚠️ 适用边界SQL 直接操作 users 和 roles 表仅适用于集群模式使用外部 MySQL。单机模式使用内嵌 Derby 数据库不建议直接修改走控制台操作。验证三步确保锁住了# 测试1无认证请求 → 必须403curl-XGEThttp://localhost:8848/nacos/v1/cs/configs?dataIddb.passwordgroupDEFAULT_GROUP# 期望{status:403,message:unknown user!}# 测试2正确认证 → 必须200如果配置存在或404配置不存在curl-XGEThttp://localhost:8848/nacos/v1/cs/configs?dataIddb.passwordgroupDEFAULT_GROUP\-HAuthorization: Bearer your_token# 期望200 或 404不能是 403# 测试3低权限用户访问高权限资源 → 必须403# 用 dev namespace 用户的 token 访问 prod namespace 的配置curl-XGEThttp://localhost:8848/nacos/v1/cs/configs?dataIddb.passwordgroupDEFAULT_GROUPnamespaceIdprod\-HAuthorization: Bearer dev_user_token# 期望403一张图带走安全配置上线清单全部通过未通过新部署或存量未开认证的 NacosStep 1开认证 换密钥Step 2改默认密码Step 3建角色 绑权限验证三部曲全部通过?上线检查配置文件对照参数表排查必要时回滚备份⚠️ 所有节点同一密钥⚠️ ≥12位含大小写数字符号⚠️ 最小权限原则只看/改需要的namespace截图直接当上线 Checklist 用。三步按顺序走每步有验证命令不通过不进入下一步。不适用这套方案的情况情况一纯内网部署且已有统一认证网关。如果你的 Nacos 只在内网、客户端通过 mTLS 连接、所有流量经过 API 网关做了一层认证——Nacos 自身的认证可以不开。前提是你确实有网关层的认证且经过验证。情况二单机开发/测试环境。本地开发用的 standalone Nacos只在你本机 localhost 上跑。不开认证问题不大。但不要把这个习惯带上生产。你们的 Nacos 开了认证吗评论区留数字1开了自定义了密钥 2开了但用的默认密钥 3没开纯内网 4没开我也不确定有没有暴露。选 4 的别慌看完这篇就够了。
Nacos 认证关闭的代价有多大
发布时间：2026/7/7 8:43:10
Nacos 认证关闭的代价有多大Nacos 从测试环境推到了生产。部署脚本跑得很顺利——解压、改 cluster.conf、startup.sh。8848 端口通了服务注册正常灰度发布正常。20 分钟后在公网扫到了这个 8848 端口拿到了所有命名空间下的所有配置——数据库密码、Redis 密码、消息队列的 AK/SK、第三方支付的密钥。全部明文。一览无余。问题出在哪Nacos 2.x 的认证默认是关闭的。application.properties里一行nacos.core.auth.enabled默认为 false。新部署的 Nacos 控制台直接裸在 8848 端口上任何人都能访问。本文基于 Nacos 2.3.x一步一步把认证锁死——不只是打开开关而是把账号、密钥、权限、namespace 四个层面都封住。⚠️ 本文基于 Nacos 2.3.x2024年12月发布。如果你是 1.x 版本1.4.x 及以下认证机制完全不同——1.x 使用nacos.core.auth.default.token.secret.key作为默认密钥不推荐生产继续使用。⚠️ 如果你正在运行一个认证未开启的 Nacos 实例先改配置立即重启。在此期间在防火墙层临时封掉 8848 和 9848 的入站流量。前置条件项目说明Nacos 版本2.3.x推荐最新稳定版数据库MySQL 5.7 或 8.0cluster 模式必须操作系统Linux本文以 CentOS 7 为例其他 Linux 同理客户端版本nacos-client 2.3.0操作权限Nacos 部署目录的读写权限 MySQL 的 DDL 权限 如果你还没部署 Nacos先看这篇集群部署Nacos 集群部署——3 台机器7 个步骤1 小时上线第一步打开认证开关 替换密钥1.1 修改 application.properties# 文件nacos/conf/application.properties # 认证开关生产环境必须 true nacos.core.auth.enabledtrue nacos.core.auth.system.typenacos # 自定义身份认证密钥 # 必须替换为新的 Base64 编码密钥长度≥32字符 # 生成方式openssl rand -base64 32 # 示例不要直接用这个自己生成 nacos.core.auth.plugin.nacos.token.secret.keyVGhpc0lzTXlDdXN0b21TZWNyZXRLZXlGb3JOYWNvc0F1dGhBbmRTZWN1cml0eQ # 身份认证过期时间秒 nacos.core.auth.plugin.nacos.token.expire.seconds18000 # 服务端默认关闭通过 User-Agent 识别请求来源 nacos.core.auth.enable.userAgentAuthWhitefalse每行参数的作用参数作用不改的后果auth.enabledtrue开启认证不开裸奔token.secret.keyJWT 签名的密钥用默认值所有人都能用默认密钥伪造 Tokentoken.expire.secondsToken 有效期默认18000s5h太长Token泄漏后长期有效太短频繁重新登录userAgentAuthWhitefalse禁止通过 User-Agent 绕过认证设为 true某些 HTTP 客户端可以不走认证1.2 生成自己的密钥# 在 Linux/Mac 上执行openssl rand-base6432# 输出类似VGhpc0lzTXlDdXN0b21TZWNyZXRLZXlGb3JOYWNvc0F1dGhBbmRTZWN1cml0eQ把输出的字符串填到token.secret.key里。每个 Nacos 节点用同一个密钥。密钥不匹配的节点认证全部失败客户端直接无法连接。 Nacos 2.x 使用 JWTJSON Web Token做身份认证和 1.x 的固定 Token 机制不同。用默认密钥等于没认证——原理拆过临时实例走左边持久化走右边——拆开那 3 行 if 里的认证链路1.3 重启并验证cdnacos/binshshutdown.shshstartup.sh-mcluster# cluster 或 standalone# 验证认证是否生效# 访问控制台 → 应强制跳转登录页# 直接 curl API → 应返回 403curl-XPOSThttp://localhost:8848/nacos/v1/cs/configs?dataIdtestgroupDEFAULT_GROUP# 期望输出{timestamp:...,status:403,error:Forbidden,message:unknown user!,path:/nacos/v1/cs/configs}验证清单控制台需要登录才能访问未登录状态下直接调用 API 返回 403默认账号 nacos/nacos 可以登录所有集群节点使用相同的token.secret.key第二步修改默认管理员密码认证打开后第一个要改的就是默认密码。nacos/nacos 是最容易被扫到的凭证。2.1 控制台方式推荐登录 Nacos 控制台 → 权限控制 → 用户列表 → 找到 nacos 用户 → 修改密码。2.2 SQL 方式集群模式-- 连接到 Nacos 使用的 MySQL 数据库USEnacos_config;-- 直接修改 users 表-- BCryptPasswordEncoder 加密新密码-- 以下示例密码为 Nacos2024Prod用自己的替换UPDATEusersSETpassword$2a$10$EuWPZUmCZ4G3GkIuLIL7COoNJ3kZ5HmQU7qO3P/hVSqFE2wAMNdReWHEREusernamenacos;新密码建议至少 12 位包含大写、小写、数字、特殊字符不包含 nacos、admin、root 等常见词使用了 BCrypt 加密后存储什么时候用 SQL 方式批量初始化或自动化部署脚本场景下。日常管理用控制台即可。第三步按 Namespace 隔离权限认证开完后所有人的权限是一样的——都能看所有 namespace、所有配置。生产环境需要按环境、按团队做隔离。3.1 创建 Namespace 专属角色Nacos 2.x 的角色体系是角色 → 权限 → 资源。用户 张三prod 运维角色ROLE_PROD_ADMIN用户 李四dev 开发角色ROLE_DEV_USER权限对 prod namespace所有配置的读写权限对 dev namespace配置的只读控制台操作路径权限控制 → 角色管理 → 新建角色 角色名: ROLE_PROD_CONFIG_ADMIN 用户名: 不填后续绑定用户 权限: resource: prod/*/* action: rw字段含义resource资源路径格式namespace/group/dataId*代表通配actionr只读w只写rw读写3.2 常用权限配置模板角色resourceaction适用场景生产配置管理员prod/*/*rw可以修改生产所有配置生产配置只读prod/*/*r只能看生产配置不能改开发环境全权dev/*/*rw开发环境随便改灰度发布专用gray/DEFAULT_GROUP/*rw只能操作灰度环境的配置注册中心管理prod/*/nacos*rw只能管理注册中心相关配置3.3 新建用户并绑定角色-- 自动化场景下用 SQL 批量创建用户INSERTINTOusers(username,password,enabled)VALUES(zhangsan_prod,$2a$10$...,1);INSERTINTOroles(username,role)VALUES(zhangsan_prod,ROLE_PROD_CONFIG_ADMIN);⚠️ 适用边界SQL 直接操作 users 和 roles 表仅适用于集群模式使用外部 MySQL。单机模式使用内嵌 Derby 数据库不建议直接修改走控制台操作。验证三步确保锁住了# 测试1无认证请求 → 必须403curl-XGEThttp://localhost:8848/nacos/v1/cs/configs?dataIddb.passwordgroupDEFAULT_GROUP# 期望{status:403,message:unknown user!}# 测试2正确认证 → 必须200如果配置存在或404配置不存在curl-XGEThttp://localhost:8848/nacos/v1/cs/configs?dataIddb.passwordgroupDEFAULT_GROUP\-HAuthorization: Bearer your_token# 期望200 或 404不能是 403# 测试3低权限用户访问高权限资源 → 必须403# 用 dev namespace 用户的 token 访问 prod namespace 的配置curl-XGEThttp://localhost:8848/nacos/v1/cs/configs?dataIddb.passwordgroupDEFAULT_GROUPnamespaceIdprod\-HAuthorization: Bearer dev_user_token# 期望403一张图带走安全配置上线清单全部通过未通过新部署或存量未开认证的 NacosStep 1开认证 换密钥Step 2改默认密码Step 3建角色 绑权限验证三部曲全部通过?上线检查配置文件对照参数表排查必要时回滚备份⚠️ 所有节点同一密钥⚠️ ≥12位含大小写数字符号⚠️ 最小权限原则只看/改需要的namespace截图直接当上线 Checklist 用。三步按顺序走每步有验证命令不通过不进入下一步。不适用这套方案的情况情况一纯内网部署且已有统一认证网关。如果你的 Nacos 只在内网、客户端通过 mTLS 连接、所有流量经过 API 网关做了一层认证——Nacos 自身的认证可以不开。前提是你确实有网关层的认证且经过验证。情况二单机开发/测试环境。本地开发用的 standalone Nacos只在你本机 localhost 上跑。不开认证问题不大。但不要把这个习惯带上生产。你们的 Nacos 开了认证吗评论区留数字1开了自定义了密钥 2开了但用的默认密钥 3没开纯内网 4没开我也不确定有没有暴露。选 4 的别慌看完这篇就够了。
 获取与实战)
