Spring Cloud Config使用Vault出现secret/data/app异常请求问题咨询

当前生产环境使用Spring Cloud 2.2.6.RELEASE版本的Spring Cloud Config作为配置中心，以Vault作为配置存储介质。近期Vault运维团队上报集群请求量异常偏高，通过Splunk日志排查发现两类混合的请求：一类是拉取secret/data/application路径的正常公共配置请求，另一类是大量无业务对应关系的secret/data/app路径读取请求，需要明确这类异常请求的触发原因、排查路径及对应解决方案。

观测到的异常请求结构 #

{
  "auth": {
    "policies": [],
    "token_issue_time": "2020-10-16T16:28:12-05:00",
    "token_policies": [],
    "token_ttl": 34164000,
    "token_type": "service"
  },
  "request": {
    "client_token": "hmac-sha256:48482518080211c5392d4a28f00838a8e83c404a7b5587eeb19e7d0dc73f8206",
    "client_token_accessor": "hmac-sha256:c33c41206e025bfd02eb4b4293b9cdec29d4cfda3a5118f4dea28754888ce502",
    "id": "96676538-fe03-1eaa-d25d-f0bd942072fc",
    "mount_type": "kv",
    "namespace": {},
    "operation": "read",
    "path": "secret/data/app",
    "remote_address": "156.36.248.6"
  },
  "time": "2021-04-23T17:59:55.815091744Z",
  "type": "request"
}

异常请求的核心触发原因 #

• 旧版本的路径递归回溯逻辑：Spring Cloud Vault 2.2.x分支（对应2.2.6.RELEASE版本）的默认配置加载逻辑，会在拉取应用专属配置时，对带分隔符的多段应用名做逐段截断递归查找。比如应用名配置为app-payment-core，加载时会依次尝试读取全路径secret/data/app-payment-core、截断后的secret/data/app-payment、最终截断到一级路径的secret/data/app，且该逻辑没有短路缓存判断，每次配置刷新都会重复触发全链路读取，直接拉高请求量。
• 旧版本默认context的兼容bug：2.2.6版本保留了对早期Spring Cloud Vault版本的配置兼容逻辑，早期KV后端的默认配置路径为app，当应用配置没有显式指定spring.cloud.vault.generic.default-context时，兼容逻辑会自动加载默认的app路径配置，触发非预期的读取请求。
• 缓存机制失效导致的请求放大：该版本的Vault配置客户端默认本地缓存TTL较短，若服务侧频繁触发配置刷新（如Actuator refresh被定时任务调用、配置加载失败进入循环重试），会重复触发所有递归路径的读取流程，进一步放大secret/data/app路径的请求量。

排查定位思路 #

• 关联请求来源：通过日志中记录的remote_address、client_token值，匹配Vault侧的token权限关联信息和服务实例IP清单，定位发起请求的具体服务实例。
• 开启客户端调试日志：将org.springframework.cloud.vault.config包的日志级别调整为DEBUG，即可在客户端日志中看到所有实际发起的Vault读取路径，直接定位触发secret/data/app请求的代码执行链路。
• 校验实际生效配置：通过Spring Boot Actuator的/env端点，检查spring.cloud.vault.application-name、spring.cloud.vault.generic.default-context、spring.cloud.vault.config.lifecycle.enabled等配置项的实际生效值，排查是否存在硬编码的app路径配置残留。

对应解决方案 #

• 关闭无意义的递归查找逻辑：通过配置项spring.cloud.vault.config.lifecycle.enabled=false禁用逐段截断应用名的向上查找逻辑，仅保留显式配置的路径拉取，避免读取非预期的secret/data/app路径。
• 显式指定默认配置路径：在所有Spring Cloud Config和微服务客户端的配置中，显式设置spring.cloud.vault.generic.default-context=application，覆盖旧版本兼容逻辑加载的默认app路径值，消除冗余请求。
• 优化缓存与刷新策略：设置合理的Vault配置本地缓存TTL，关闭不必要的定时refresh触发；给配置加载的重试逻辑增加指数退避策略，避免循环重试造成的请求放大。
• 临时访问限流：在Vault侧通过策略配置，对secret/data/app这类非业务约定的路径配置拒绝访问规则，直接拦截无效请求，降低Vault集群的请求压力。

内容的提问来源于stack exchange，提问作者emoritz