Nacos配置信息泄露事故复盘：从日志脱敏到凭据加固

Nacos配置信息泄露事故复盘：从日志脱敏到凭据加固

发布时间：2026/9/10 9:55:38
Nacos配置信息泄露事故复盘：从日志脱敏到凭据加固 1. 那次线上重启Nacos 明文密码被日志完整打印出来事情发生在一个平平无奇的发布窗口。我们当时正在升级 Spring Cloud Alibaba 的小版本Nacos 侧统一开启了鉴权之前一直是内网裸奔的状态。发到生产环境配置中心自然就拉不到了应用启动失败。我钻进日志聚合平台翻到那一条启动错误日志整个人都愣了NacosConfigProperties{serverAddr10.10.12.33:8848, usernamenacos, passwordnacosProd#2023, namespaceprod-v2, accessKeyLTAI5t..., secretKey9k3j2o..., ...}说实话那一刻我脑子里冒出来的第一句话是这要是被安全团队看到我写成八份检讨都不过分。Nacos 的账号密码、RAM 角色的 accessKey/secretKey就那么大摇大摆地躺在 error 级别日志里跟着日志采集组件进了集中存储七天的保留期等于裸奔七天。这事其实不是偶发。后来我翻了半天发现 Spring Cloud Alibaba 的 Nacos 客户端在构建ConfigService失败时部分异常处理会把承载全部启动参数的Properties对象直接交给日志框架。而Properties.toString()是不过滤敏感词的key 是什么就打印什么。如果我们用的是 Spring Boot 的ConfigurationProperties绑定某些绑定过程也会连带输出绑定源。你以为写进bootstrap.yml就算万事大吉实际凭据会在运行期被各种入口翻出来晒。这篇文章就是围绕这次事故展开的。我会完整还原从复现、源码定位到提交 PR 修复的整个过程并给大家一份可以直接照抄的 Nacos 凭据加固清单。2. 复现路径什么样的配置和异常会让 accessKey/secretKey 暴露先说清楚 Nacos 客户端的凭据来源。用 Spring Cloud Alibaba 的时候最常规的配置长这样spring: cloud: nacos: config: server-addr: 127.0.0.1:8848 namespace: dev group: DEFAULT_GROUP file-extension: yaml username: nacos password: nacos discovery: server-addr: 127.0.0.1:8848 username: nacos password: nacos如果对接的是阿里云上的 Nacos 或者通过 RAM 角色访问还会出现一组字段spring: cloud: nacos: config: access-key: LTAI5tAbC... secret-key: 9k3j2o...问题的第一层出在NacosConfigProperties这个类上。它是一个典型的ConfigurationProperties字段和配置项一一对应其中password、accessKey、secretKey全是普通 String没有任何脱敏限制。它存在的意义就是承载用户输入然后把这些字段搬运到一个Properties对象里传给 Nacos 原生客户端。这里必须强调一点它不是日志专用 DTO却经常被日志框架当成字符串整个打出来。我耗时最长的其实是复现。你光看代码觉得“理论上可能有风险”但真正的触发条件很苛刻需要同时满足Nacos 服务端开了鉴权nacos.core.auth.enabledtrue客户端配置的用户名密码错误或者 accessKey 没有对应 RAM 角色权限Nacos 服务端不可达或者配置拉取超时项目里有人把org.springframework.cloud.alibaba.nacos.NacosConfigProperties或者它携带的Properties参对象放进了log.error的参数列表。前三条是启动期间任何一个小故障都会触发的第四条才是最致命的一环。因为 Java 日志框架拼接参数时如果传入的是对象会自动调用toString()。java.util.Properties.toString()继承自Hashtable它会把整个键值对清单原样输出。你只要写一行log.error(init nacos config failed, properties {}, properties);密码和密钥就全出去了。还有一个更隐蔽的入口历史版本的server-addr允许把用户名密码写在 URL 参数里比如spring: cloud: nacos: config: server-addr: 127.0.0.1:8848?usernamenacospasswordnacosProd#2023这种写法能用但非常危险。Nacos 客户端在解析server-addr时会把 URL 参数作为属性一旦调试日志打开或者异常信息把完整地址拼进去凭据就跟着地址一起被打印。后来官方文档明确不推荐这个用法改成了独立的username和password字段就是因为这个坑。复现步骤其实很简单我直接贴出来大家可以自己在测试环境试创建一个 Spring Boot 项目版本用Spring Boot 2.7.x加Spring Cloud Alibaba 2021.0.5.0引入spring-cloud-starter-alibaba-nacos-configbootstrap.yml里配置一个故意写错的password日志级别设置成DEBUG重点观察com.alibaba.nacos和org.springframework.cloud.alibaba.nacos两个包启动应用等启动失败然后去控制台搜password或secretKey。我在本地一顿操作后启动了十次有八次能在堆栈里看到带敏感字段的属性列表。另外两次不是没泄露而是 Nacos 客户端走的连接池兜底逻辑不一样异常消息没有把Properties传出来。也就是说这个漏洞和网络异常模式强相关属于“时灵时不灵”的类型更容易被忽略。3. 源码链路NacosConfigProperties 里的凭据是怎么一路传到日志的排查问题时我没停留在“换密码 重启”的层面而是把 Spring Cloud Alibaba 的源码扒了一遍。这里把我的定位过程整理成一条链路方便大家一起看。3.1 链路起点NacosConfigProperties 的字段绑定NacosConfigProperties位于com.alibaba.cloud.nacos.NacosConfigProperties包下核心字段大概是这样的简写ConfigurationProperties(prefix spring.cloud.nacos.config) public class NacosConfigProperties { private String serverAddr; private String username; private String password; private String accessKey; private String secretKey; private String namespace; private String group; private String contextPath; private String fileExtension properties; ... }Spring Boot 启动时会把bootstrap.yml里的内容绑定到这个对象上。绑定过程是自动的字段哪怕没有Value注解也能拿到值。3.2 链路中间NacosConfigManager 把对象搬运成 Properties继续往下走NacosConfigManager里有个方法会把这些配置组装成 Nacos 原生客户端需要的Propertiespublic ConfigService getConfigService() throws NacosException { if (configService null) { configService NacosFactory.createConfigService(getConfigProperties()); } return configService; } private Properties getConfigProperties() { Properties properties new Properties(); properties.put(PropertyKeyConst.SERVER_ADDR, this.configProperties.getServerAddr()); properties.put(PropertyKeyConst.NAMESPACE, this.configProperties.getNamespace()); if (this.configProperties.getUsername() ! null) { properties.put(PropertyKeyConst.USERNAME, this.configProperties.getUsername()); } if (this.configProperties.getPassword() ! null) { properties.put(PropertyKeyConst.PASSWORD, this.configProperties.getPassword()); } if (this.configProperties.getAccessKey() ! null) { properties.put(PropertyKeyConst.ACCESS_KEY, this.configProperties.getAccessKey()); } if (this.configProperties.getSecretKey() ! null) { properties.put(PropertyKeyConst.SECRET_KEY, this.configProperties.getSecretKey()); } ... return properties; }PropertyKeyConst是 Nacos 客户端定义的常量类最终Properties会被ConfigFactory.createConfigService(properties)消费。3.3 链路末端异常分支把整个对象交给日志到这一步Properties对象还是干净的只是被当成配置参数传递。真正出问题的是异常分支。我去 Log 系统里翻了各种 error 日志格式发现有两种典型写法log.error(Failed to create nacos config service, properties {}, properties, e);以及catch (NacosException e) { log.error(Init Nacos config service failed, serverAddr {}, properties {}, serverAddr, properties, e); }我在和几个维护者交流后确认这些日志本意是方便排障但明显没有考虑敏感字段。毕竟谁也不会在写日志的时候天真地认为“Nacos 密码也要打码”。可现实就是一个Properties对象传进去整个 map 全被toString()兜底输出了。这就是我这次提交 PR 的核心触发点。当时在 GitHub 上搜 issue其实已经有人提过类似问题NacosConfigProperties.toString() may leak accessKey if printed by logger。但因为没有统一的修复方案一直挂着。我盯了半天决定自己上手。4. 提交 PR我如何把敏感信息在日志层和异常层一起收口修复方案一开始我给的比较激进我想改NacosConfigProperties的getPassword()和getSecretKey()让它们对外返回******。结果很快被维护者否决理由很简单——这个类最终要把真实凭据传给 Nacos 客户端改 getter 等于把功能改坏。所以最终思路收敛到三个层面只动日志输出和异常信息不碰凭证使用链路。4.1 加一个 SensitiveDataUtils日志统一走脱敏出口我新建了一个工具类负责把属性对象转换成适合日志输出的字符串敏感键统一打码package com.alibaba.cloud.nacos.utils; public final class SensitiveDataUtils { private static final String MASK ******; private static final ListString SENSITIVE_KEYWORDS Arrays.asList( password, secretkey, accesskey, token, credential ); private SensitiveDataUtils() { } public static String toSafeLogString(Properties properties) { if (properties null) { return null; } ListString names new ArrayList(properties.stringPropertyNames()); Collections.sort(names); StringBuilder sb new StringBuilder(); for (int i 0; i names.size(); i) { if (i 0) { sb.append(, ); } String name names.get(i); String value properties.getProperty(name); sb.append(name).append().append(isSensitiveKey(name) ? MASK : value); } return sb.toString(); } public static boolean isSensitiveKey(String key) { if (key null) { return false; } String lowerKey key.toLowerCase(); return SENSITIVE_KEYWORDS.stream().anyMatch(lowerKey::contains); } }这个工具类尽量做得轻量不引入额外依赖只做字符串拼接。排序是为了让日志输出稳定方便后续自动化断言对比。你可能会想为什么用contains而不是精确匹配因为 Nacos 客户端不同版本对 key 的大小写和拼写有差异比如secretKey、accessKey在PropertyKeyConst里是驼峰但在某些上下文里会变成SECRET_KEY、ACCESS_KEY统一小写后contains更稳。然后我替换了NacosConfigManager等关键类里的日志写法catch (NacosException e) { log.error(Init nacos config service failed, properties {}, SensitiveDataUtils.toSafeLogString(properties), e); throw e; }这样即使异常堆栈还在日志文本里出现的密码、AccessKey 和 SecretKey 也会变成******问题定位不受影响敏感信息却不再裸奔。4.2 处理 server-addr 里夹带凭据的兼容老写法我顺手检查了全局代码里所有打印serverAddr的地方发现有些老模块还在把server-addr当完整 URL 打。如果用户沿用127.0.0.1:8848?usernamenacospasswordnacos的写法那serverAddr字符串本身就是泄露源。所以我加了一个方法public static String maskServerAddr(String serverAddr) { if (serverAddr null) { return null; } return serverAddr.replaceAll((?i)(username|password)[^], $1******); }在日志输出统一使用maskServerAddr(serverAddr)保证不带明文凭据。这个方法相对保守即使 Nacos 后续版本支持更复杂的 URL 参数只要参数名里带username或password就能被覆盖到。4.3 actuator/env 也要防一手单看日志还不够。Spring Boot 的/actuator/env端点会把配置属性全部列出来默认脱敏规则只认*password*、*secret*、*key*、*token*这几种模式。如果你自定义了一个叫spring.cloud.nacos.config.credential的属性它不会自动匹配默认脱敏规则就会明文出现在接口返回里。因此我在示例配置里补了一段management: endpoint: env: keys-to-sanitize: - spring.cloud.nacos.*.password - spring.cloud.nacos.*.access-key - spring.cloud.nacos.*.secret-key - spring.cloud.nacos.*.credentialSpring Boot 3.x 还支持更灵活的SanitizingFunction返回SanitizableData.SANITIZED就把值打码。推荐大家在新项目里用函数式配置比维护一长串脱敏规则更优雅Bean SanitizingFunction nacosCredentialSanitizingFunction() { return (endpoint, key, value) - { if (key.startsWith(spring.cloud.nacos.) (key.contains(password) || key.contains(access-key) || key.contains(secret-key) || key.contains(credential))) { return SanitizableData.SANITIZED; } return value; }; }这几个层面合起来才算把“日志打印”和“配置端点暴露”两个口子都堵上。4.4 单元测试与 checkstyle 调整PR 里我补了三个单测覆盖SensitiveDataUtils.toSafeLogString、maskServerAddr和isSensitiveKey确保后续维护者改代码时不会把脱敏逻辑改没。测试用例最关键的是“输出结果里不能出现真实密码字符串”Test void maskSensitiveProperties() { Properties props new Properties(); props.setProperty(serverAddr, 127.0.0.1:8848); props.setProperty(username, nacos); props.setProperty(password, nacosTestPassword); props.setProperty(secretKey, abcdef123456); String safeString SensitiveDataUtils.toSafeLogString(props); assertThat(safeString) .doesNotContain(nacosTestPassword) .doesNotContain(abcdef123456) .contains(password******) .contains(secretKey******) .contains(usernamenacos); }注意最后一行是重点username不被脱敏因为用户名在绝大多数团队里不算高敏信息打码反而会影响排障。如果你的公司安全规范认为用户名也算敏感把username加进关键字列表即可。提交前还遇到了 Spring Cloud Alibaba 的 checkstyle 规则禁止魔法值、禁止匿名内部类过长、import 不能使用*通配符等等。我一开始写得太随意被 CI 打了回来改了两轮才通过。这里也提醒想贡献开源的朋友先看一遍仓库的checkstyle.xml和CONTRIBUTING.md能省很多事。5. 项目维护者的视角为什么“脱敏”属于接口契约的一部分PR 提交之后维护者提了两个非常到位的问题我这里如实记录一下它们比我写的代码价值更高。第一个问题“你为什么没改NacosConfigProperties.toString()”我当时的回复是改toString()只能防住日志框架调用对象字符串化的场景防不住Properties对象被直接放进日志参数的场景。因为Properties有自己独立的toString()它不会调用NacosConfigProperties的。后来维护者拍板两边都要改NacosConfigProperties里打印自身用脱敏后的摘要NacosConfigManager和异常分支统一走SensitiveDataUtils。这让我意识到一个类只要能被日志打印它的toString()其实已经算“接口契约”的一部分应该默认对外安全。第二个问题“你为什么要用自定义工具类而不是直接依赖日志框架的脱敏能力”当时有维护者建议直接用 logback 的%replace或者 Logstash 的脱敏 pattern。我的回答是不是所有项目都统一用 logback有的用 log4j2有的走 Spring Cloud Sleuth ELK自定义工具类在框架底层是最可控的不依赖用户侧的日志配置。况且日志框架的脱敏通常只处理已格式化的消息文本碰上Properties这种对象参数时它先调用toString()再处理等于盐已经撒进锅里了晚了。这两个问题让我重新理解了“安全修复”的边界不是修一条日志命令而是给所有可能输出凭据的路径设置统一出口。一旦某个敏感对象被设计成“可被日志打印”就必须保证它打印出来的样子是安全的。这不是过度设计这是接口契约。PR 最终被合并到了对应版本的维护分支同时我也提了一个 backport 到2021.x的版本。整体改动很小总共不到 200 行代码加上测试但它解决的是生产环境里最容易被忽视的一类事故。后来我给团队做分享时反复强调一句话凭据泄露不太需要什么高超攻击手段往往只是日志框架的一次默认 toString()。6. 从这次修复里沉淀出的 Nacos 鉴权加固清单最后把我这次排查、修复和回访过程中全部踩过的点整理成一份检查清单。如果你现在正用着 Spring Cloud Alibaba Nacos建议逐条对照不只是改代码还要改流程。6.1 配置层面的自查项检查bootstrap.yml、application.yml里是否硬编码了 Nacos 的password、accessKey、secretKey。如果有改成环境变量或 Kubernetes Secret 注入。检查是否有老代码使用server-addr: 127.0.0.1:8848?usernamexxxpasswordxxx这种写法。有的话立刻迁移到独立字段。检查/actuator/env暴露情况如果生产环境开了 actuator确认脱敏规则覆盖到所有 Nacos 相关属性而不是只靠默认规则。检查日志采集配置确认logstash、filebeat或fluentd没有把敏感字段原样转发到第三方的日志平台。日志落盘之前就应该把明文密码过滤掉而不是指望事后清理。6.2 Nacos 服务端的安全基线确认nacos.core.auth.enabledtrue已经开启。我见过不少生产集群application.properties里配了用户名密码但鉴权开关没打开等于大门虚掩。不要使用默认的nacos/nacos账号。创建独立的管理员账号并定期轮换密码。命名空间不要使用默认业务按环境和域拆分各命名空间之间通过权限隔离。如果控制台暴露在公网或半公网环境务必配合网关或防火墙做白名单限制Nacos 的未授权访问漏洞很多时候就是网络边界没守住。6.3 开发流程层面的习惯养成日志格式里不要直接用{}打印任意Properties或Map对象。如果确实需要打印务必先经过脱敏工具。异常处理中不要把整个配置对象塞进异常消息至少要核对一下这个对象里有没有敏感字段。安全测试应该把“日志中搜索密码、accessKey、secretKey”作为一个常规用例纳入发布前的安全检查。订阅 Spring Cloud Alibaba 和 Nacos 的 Release Notes关注安全相关的修复项。你不可能记住所有 CVE但至少要在版本升级时确认修复范围。这次修复从发现到合并前前后后花了接近三周中间还被 checkstyle 教育了好几次。但回看整个过程最有价值的不只是那几十行脱敏代码而是让我把所有和 Nacos 凭据相关的路径都认真捋了一遍。以后再遇到别人说“Nacos 密码在日志里被打出来了”我第一反应不再是改配置而是先去翻代码里有多少地方把Properties当日志参数传了。毕竟凭据泄露这种问题堵住一条路不够要所有路口都亮红灯才算数。