Java项目生产环境使用带敏感凭证的配置文件的最优方案是什么？

第一个问题解答 #

• 完全不能沿用现有把带凭证的properties放在src/main/resources的方案，安全性根本不达标。
• 这个路径下的文件会在构建时直接打进JAR包，等于明文凭证跟着JAR包走所有流程：只要有人能拿到JAR包，直接解压就能拿到凭证，不管是代码仓库泄露、部署包流转被人截获、甚至测试环境的包外流，都会直接导致敏感凭证泄露，属于非常低级的安全风险。

第二个问题解答 #

• 带凭证的配置文件本来就不应该直接推送到生产，更不能跟着部署包一起打包分发，目前业界有很多成熟的落地方案，你可以根据自己的部署场景选：

生产环境凭证配置主流最佳实践 #

1. 外置配置+权限管控（适合中小规模单体部署） #

• 把不带敏感信息的默认配置保留在src/main/resources打到JAR里，带凭证的生产配置单独抽出来，存放到生产服务器的独立目录，比如/opt/svc-config/你的项目名/。
• 启动JAR时指定加载外置配置：如果是Spring Boot项目可以用启动参数java -jar your-app.jar --spring.config.additional-location=/opt/svc-config/你的项目名/application-prod.properties；普通Java项目也可以自己实现启动参数传配置路径的逻辑，读取外部配置覆盖默认配置即可。
• 外置配置文件只给运行JAR的服务账号开只读权限，其他账号全部禁止访问，必要时可以对配置里的敏感字段做对称加密，程序启动时解密读取，进一步降低泄露风险。

2. 配置中心统一管理（适合微服务多实例部署） #

• 用Nacos、Apollo、Spring Cloud Config等成熟配置中心托管所有配置，敏感字段在配置中心做加密存储，只有程序运行时拉取才会解密为明文，运维人员在后台也看不到明文凭证。
• JAR包只需要保留配置中心的接入地址和权限密钥，不需要本地存储任何带敏感信息的配置，还能支持配置热更新，不需要重启服务就能修改凭证。

3. 密钥托管服务（适合云原生/K8s部署） #

• 公有云部署可以直接用云厂商的KMS密钥管理服务、参数存储服务托管凭证，程序通过云服务的角色权限拉取凭证，全程不需要本地存储任何密钥信息。
• K8s集群部署可以把凭证存在集群的Secret资源中，挂载到Pod的运行环境或者文件系统，Secret本身做加密存储，只有对应服务的Pod有权限访问，运维可以单独管控Secret的操作权限，不需要跟着镜像或部署包流转。

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