AWS Secrets Manager如何与本地k8s集群实现集成对接
本地自建K8s集群原生对接AWS Secrets Manager落地方案
你此前在EKS上使用的AWS Secrets Manager CSI Provider本身并非EKS专属绑定组件,只是官方默认文档优先给出了EKS环境下的OIDC认证配置流程,本地自建集群只要调整认证层配置,就能完全复用这套CSI驱动能力,实现K8s原生方式对接AWS Secrets Manager,不需要在节点或业务Pod中部署AWS CLI,也不需要在AWS侧配置OIDC集群身份关联。
核心实现原理
整套方案基于K8s官方Secrets Store CSI Driver扩展框架实现,AWS Provider作为后端适配插件,仅将EKS环境默认依赖的OIDC联邦认证替换为本地集群可用的IAM认证模式,上层的Secret挂载、轮转、同步为K8s原生Secret等能力和EKS环境完全一致,业务侧无感知。
具体部署流程
- 部署通用版Secrets Store CSI Driver
直接使用上游社区通用版本的Secrets Store CSI Driver,不要选用EKS专属的托管Addon版本,组件以DaemonSet形式运行在集群节点,安装过程不依赖节点预装任何AWS相关工具。 - 部署AWS Secrets Manager CSI Provider
和EKS环境部署的AWS Provider为完全相同的组件,该组件本身无EKS环境强绑定逻辑,仅默认示例配置采用了EKS OIDC认证参数。 - 配置非OIDC模式的IAM认证(和EKS部署的核心差异)
无需配置OIDC集群ID,可根据自身安全要求二选一配置认证:- 静态凭证认证(最易落地)
提前创建拥有AWS Secrets Manager对应密钥读取权限的IAM用户,生成访问密钥对,以K8s Secret形式存储在kube-system等受权命名空间,为AWS Provider的DaemonSet工作负载配置环境变量读取该凭证,所有拉取密钥的请求均由CSI驱动组件发起,节点、业务Pod完全不感知凭证存在,也无需安装AWS CLI。
核心配置片段参考:# AWS Provider DaemonSet 环境变量配置片段 env: - name: AWS_ACCESS_KEY_ID valueFrom: secretKeyRef: name: aws-sm-csi-cred key: access_key_id - name: AWS_SECRET_ACCESS_KEY valueFrom: secretKeyRef: name: aws-sm-csi-cred key: secret_access_key - name: AWS_REGION value: "替换为你的AWS资源所在区域" - 临时凭证认证(安全等级更高)
如果本地集群节点可通过AWS IAM Roles Anywhere能力获取短期临时凭证,可直接将凭证文件路径映射到AWS Provider的Pod内,不需要存储长期静态AK/SK,也无需配置OIDC关联,凭证可自动轮换。
- 静态凭证认证(最易落地)
- 创建SecretProviderClass资源
你此前在EKS环境中编写的SecretProviderClass配置YAML可直接复用,无需修改字段,按业务需求定义需要拉取的密钥列表、容器内挂载路径、是否同步为K8s原生Secret等参数即可。 - 业务负载挂载验证
业务Pod的配置和EKS环境完全一致,仅需要添加对应volume,将Secrets Store CSI驱动对应的卷挂载到容器指定路径,即可直接读取AWS Secrets Manager中存储的密钥内容,业务侧无需调用AWS SDK、无需感知认证逻辑。
方案特性说明
- 完全遵循K8s原生存储扩展规范,和EKS环境下的使用体验完全一致,业务侧零改造
- 无需在集群节点或业务Pod中预装AWS CLI,所有和AWS Secrets Manager的交互逻辑均由CSI Provider组件完成
- 无需在AWS侧配置OIDC身份提供商、无需关联本地集群的OIDC发行地址,认证逻辑全部下沉到CSI组件层
- 原生支持密钥自动轮转,CSI驱动会按配置的轮询周期自动拉取最新版本的密钥,同步更新挂载目录和关联的K8s原生Secret
注意:如果选择静态凭证认证方案,建议严格限制对应IAM用户的权限范围,仅开放需要读取的Secrets Manager资源访问权限,避免权限过度扩散。
内容的提问来源于stack exchange,提问作者sethu2912
相关产品推荐
相关产品推荐

