SpringBoot应用将spring.security.*属性存于配置服务器是否属最佳实践？

关于最佳实践的结论 #

这是常见且推荐的实践，但需要搭配容错与安全强化措施：

• 集中管理spring.security.*配置能提升多实例、多环境部署场景下的配置一致性和可维护性，比如统一密码策略、角色权限规则、OAuth2参数等。
• 核心敏感凭证（如加密密钥、第三方服务密钥）必须用配置服务器的加密功能存储，禁止明文暴露。

疑问1：配置服务器连接中断时，应用会无安全防护启动吗？ #

不会直接无防护启动，取决于你的配置策略：

• 若使用Spring Cloud Config，启动阶段拉取配置失败时：
  • 开启spring.cloud.config.fail-fast=true，应用会直接启动失败，避免无配置运行；
  • 若fail-fast=false，应用会加载本地默认配置或之前缓存的配置（需开启spring.cloud.config.cache.enabled=true）。
• 关键要在本地配置中设置兜底安全规则，比如默认拒绝所有请求、启用本地基本认证账号，确保配置服务器不可用时，应用仍有基础防护，而非完全开放。

疑问2：攻击者触发上下文刷新时，连接中断会导致安全防护失效吗？ #

不会直接导致安全防护失效：

• Spring Security的核心配置Bean（如SecurityFilterChain）默认不支持动态刷新，除非你主动给相关配置类标记@RefreshScope。
• 即使开启了动态刷新，刷新失败时应用会保留旧的有效安全配置，不会清空或重置为无防护状态。
• 另外，/actuator/refresh这类刷新端点必须严格权限控制，只允许内部运维人员访问，外部攻击者几乎无法触发该操作。
• 额外建议：若需动态更新安全配置，要给配置服务器连接添加重试机制，同时设置刷新失败回退策略，确保旧配置持续生效直到新配置拉取成功。

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