Spring Boot对接AWS Secrets Manager：K8s CSI驱动vs原生集成的优劣与场景

原生集成相比CSI方案损失的优势 #

• Kubernetes统一管控能力：CSI方案通过SecretProviderClass等K8s资源定义秘钥挂载规则，运维可以在集群层面统一管理所有服务的秘钥获取策略，无需修改应用代码。原生集成是应用自主拉取秘钥，运维没法通过K8s配置统一管控。
• 秘钥自动同步与轮换：CSI驱动能自动同步AWS Secrets Manager中更新的秘钥到Pod挂载卷，应用读取文件就能拿到新值，无需额外配置。原生集成要实现自动刷新，得自己配置Spring的@RefreshScope或Actuator刷新端点，额外增加复杂度。
• 跨语言兼容性：CSI是通用的K8s卷挂载方式，Python、Go等非Java应用都能直接读取挂载文件获取秘钥，不需要适配。原生集成只适用于Spring Boot应用，没法复用给其他服务。
• 权限集中管理：CSI通过K8s ServiceAccount绑定IAM角色，所有使用该账号的Pod遵循同一套权限规则，运维集中配置即可。原生集成是应用通过自身Pod的IAM角色访问秘钥，权限控制分散在应用侧，需要逐个配置。
• 低耦合的秘钥使用：CSI挂载后，应用像读本地文件一样用秘钥，不需要引入AWS SDK或Spring Cloud AWS依赖，代码更简洁，与云服务耦合度更低。原生集成必须引入相关依赖，代码里要配置读取逻辑，耦合性更高。

两种方案的适用场景 #

Spring Boot原生集成适用场景 #

• 小型Spring Boot项目：项目规模小，运维精力有限，不想额外部署维护CSI控制器组件，追求快速上手、简化运维的场景。
• 纯Spring Boot技术栈环境：集群里只有Spring Boot应用，不需要考虑多语言适配，原生集成的接入成本更低。
• 需要自定义秘钥处理逻辑：应用要针对秘钥做个性化处理，比如动态加载不同环境秘钥、结合业务做缓存等，原生集成能通过Spring配置体系灵活实现。

AWS Secrets Store CSI Provider适用场景 #

• 多语言混合的K8s集群：集群内有多种语言的服务，需要统一的秘钥管理方案，CSI能提供一致的访问方式，无需针对不同语言做适配。
• 大规模集群与统一运维：集群服务数量多，运维需要统一管控所有服务的秘钥策略、权限和轮换规则，CSI的K8s资源配置方式更适合批量管理。
• 对秘钥自动轮换有强需求：业务要求秘钥更新后无需重启应用就能生效，CSI的自动同步机制更可靠。
• 低耦合架构设计：希望应用尽可能减少与云服务的绑定，通过K8s标准卷挂载获取秘钥，代码无需感知AWS Secrets Manager，提升可移植性。

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